For those users who are satisfied with AlphaVM-free emulator (http://emuvm.com/index.php?option=com_content&view=article&id=12&Itemid=8)

and its CPU performance EmuVM (http://emuvm.com) gives availability to use the whole range of peripherals from the commercial version of AlphaVM emulator in the free version.

Now AlphaVM-free has the ability to work with additional disks, tapes, controllers, NICs, etc, memory and additional CPUs from the commercial AlphaVM-EV6
(http://emuvm.com/index.php?option=com_content&view=article&id=3&Itemid=3).

EmuVM wrote:
> For those users who are satisfied with AlphaVM-free emulator (http://emuvm.com/index.php?option=com_content&view=article&id=12&Itemid=8)
>
> and its CPU performance EmuVM (http://emuvm.com) gives availability to use the whole range of peripherals from the commercial version of AlphaVM emulator in the free version.
>
> Now AlphaVM-free has the ability to work with additional disks, tapes, controllers, NICs, etc, memory and additional CPUs from the commercial AlphaVM-EV6
> (http://emuvm.com/index.php?option=com_content&view=article&id=3&Itemid=3).
>


Nice, but it would even be nicer if we could find some price information 
about these peripherals.


I also have some remarks about the installation manual.

There is a PuTTY terminal emulator included with the package. In my 
opinion a good VT terminal emulator would be more appropriate, since 
many VMS utilities rely on VT escape sequences.

It is possible to choose between DS10, DS20 and ES40 emulation, but what 
is the difference since all three emulations have exactly the same 
peripheral limitations?

The default physical address of the emulated ethernet interface is 
AA:00:04:00:04:02. This is a DECnet Phase IV compatible address type, 
corresponding with DECnet Phase IV address 0.516. In my opinion a 
'neutral' address like 08:00:2B:00:00:01 would have been better.

These is al minimum and maximum Working Set setting, but no mention 
about the unit. Is it in bytes, kB, MB or what?

Is it possible to run two instances of the emulator at the same time on 
one system? That way it is possible to set up a cluster, and test 
cluster aware software.

On 2012-07-15, Dirk Munk <munk@home.nl> wrote:
> EmuVM wrote:
>> For those users who are satisfied with AlphaVM-free emulator (http://emuvm.com/index.php?option=com_content&view=article&id=12&Itemid=8)
>>
>> and its CPU performance EmuVM (http://emuvm.com) gives availability to use the whole range of peripherals from the commercial version of AlphaVM emulator in the free version.
>>
>> Now AlphaVM-free has the ability to work with additional disks, tapes, controllers, NICs, etc, memory and additional CPUs from the commercial AlphaVM-EV6
>> (http://emuvm.com/index.php?option=com_content&view=article&id=3&Itemid=3).
>>
>
> I also have some remarks about the installation manual.
>
> There is a PuTTY terminal emulator included with the package. In my 
> opinion a good VT terminal emulator would be more appropriate, since 
> many VMS utilities rely on VT escape sequences.
>

PuTTY _is_ a VT terminal emulator. I use it on a daily basis at work
to talk to VMS systems and run emacs locally in EDT keypad mode.
It's major compatibility annoyance for me (on Linux, I don't run PuTTY
under Windows) is that PF1 through PF4 do not function as such unless
the keypad is in application keypad mode. I also have some issues with
8 bit characters not displaying.

Apart from these issues it works just fine as a terminal emulator.

> It is possible to choose between DS10, DS20 and ES40 emulation, but what 
> is the difference since all three emulations have exactly the same 
> peripheral limitations?
>

What are the license requirements for the various systems ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2012-07-15 12:56, Simon Clubley wrote:
> On 2012-07-15, Dirk Munk <munk@home.nl> wrote:
>> EmuVM wrote:
>>> For those users who are satisfied with AlphaVM-free emulator (http://emuvm.com/index.php?option=com_content&view=article&id=12&Itemid=8)
>>>
>>> and its CPU performance EmuVM (http://emuvm.com) gives availability to use the whole range of peripherals from the commercial version of AlphaVM emulator in the free version.
>>>
>>> Now AlphaVM-free has the ability to work with additional disks, tapes, controllers, NICs, etc, memory and additional CPUs from the commercial AlphaVM-EV6
>>> (http://emuvm.com/index.php?option=com_content&view=article&id=3&Itemid=3).
>>>
>>
>> I also have some remarks about the installation manual.
>>
>> There is a PuTTY terminal emulator included with the package. In my
>> opinion a good VT terminal emulator would be more appropriate, since
>> many VMS utilities rely on VT escape sequences.
>>
>
> PuTTY _is_ a VT terminal emulator. I use it on a daily basis at work
> to talk to VMS systems and run emacs locally in EDT keypad mode.
> It's major compatibility annoyance for me (on Linux, I don't run PuTTY
> under Windows) is that PF1 through PF4 do not function as such unless
> the keypad is in application keypad mode. I also have some issues with
> 8 bit characters not displaying.
>
> Apart from these issues it works just fine as a terminal emulator.

If you are running under Linux, I would recommend xterm instead, since 
that is the only terminal application I've encountered where I haven't 
found glaring bugs in the VT100 emulation so far.

That said, putty is among the better of the buggy ones.

As for the PFn keys, that is not a problem with putty, but with X and 
how it encodes the keys. Admittedly, putty could probably have worked 
around that, if they tried.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Simon Clubley wrote:
> On 2012-07-15, Dirk Munk <munk@home.nl> wrote:
>> EmuVM wrote:
>>> For those users who are satisfied with AlphaVM-free emulator (http://emuvm.com/index.php?option=com_content&view=article&id=12&Itemid=8)
>>>
>>> and its CPU performance EmuVM (http://emuvm.com) gives availability to use the whole range of peripherals from the commercial version of AlphaVM emulator in the free version.
>>>
>>> Now AlphaVM-free has the ability to work with additional disks, tapes, controllers, NICs, etc, memory and additional CPUs from the commercial AlphaVM-EV6
>>> (http://emuvm.com/index.php?option=com_content&view=article&id=3&Itemid=3).
>>>
>>
>> I also have some remarks about the installation manual.
>>
>> There is a PuTTY terminal emulator included with the package. In my
>> opinion a good VT terminal emulator would be more appropriate, since
>> many VMS utilities rely on VT escape sequences.
>>
>
> PuTTY _is_ a VT terminal emulator. I use it on a daily basis at work
> to talk to VMS systems and run emacs locally in EDT keypad mode.
> It's major compatibility annoyance for me (on Linux, I don't run PuTTY
> under Windows) is that PF1 through PF4 do not function as such unless
> the keypad is in application keypad mode. I also have some issues with
> 8 bit characters not displaying.
>
> Apart from these issues it works just fine as a terminal emulator.

OK, maybe I've encountered older versions that were not as good. In my 
view the Ericom VT emulators were the best, they were a part of 
Pathworks. There were even special LK keyboards for this emulator.


>
>> It is possible to choose between DS10, DS20 and ES40 emulation, but what
>> is the difference since all three emulations have exactly the same
>> peripheral limitations?
>>
>
> What are the license requirements for the various systems ?

No requirements, this is the *free* version!


>
> Simon.
>

On Sunday, July 15, 2012 12:56:52 PM UTC+2, Simon Clubley wrote:
> . . .
> . . .
> PuTTY _is_ a VT terminal emulator. I use it on a daily basis at work
> to talk to VMS systems and run emacs locally in EDT keypad mode.
> It's major compatibility annoyance for me (on Linux, I don't run =
PuTTY
> under Windows) is that PF1 through PF4 do not function as such unless
> the keypad is in application keypad mode. I also have some issues with
> 8 bit characters not displaying.
> . . .
> . . .
> Simon.


I have found that PuTTY v0.61 does not respond appropriately to a $ SET TER=
M/INQUIRE since it will result in the terminal having a /NOEIGHTBIT attribu=
te even when eightbit is otherwise supported. I find it necessary to do an =
explicit $ SET TERM/EIGHTBIT to get the Code 1 Page characters of the MCS c=
haracter set from the keyboard with the needed diacritical characters for E=
uropean languages.

This was a problem whether or not I used a standard German USB PC keyboard =
or a LK461-AG connected to a PS2 keyboard port.

I have done a considerable amount of configuration testing get an exceptabl=
e level of VT compatibilty out of PuTTY, since our current customer has sta=
ndardized on PuTTY.

For a font I found the line drawing characters coming with Window's Courier=
 New 14 pt combined with "use Unicode line drawing code points" setting to =
be a good setting for VMS displays such as a $ MONITOR SYSTEM.

For remote character set I have DEC-MCS, to accurately portray what OpenVMS=
 recognizes by default.

For the Keyboard Function Keys and Keypad settings the ESC[n~ setting is su=
rprisingly working best for me, not the Xterm, VT400 or VT100+ settings.

I hope this helps someone else.

By the way, before  PuTTY, I have been using Hummingbird Exceed for many ye=
ars. With Exceed it is important to use the "DEC Supplementary" Character S=
et, otherwise the VMS Screen Editors EDT and/or TPU will fail.


Cheers!

Keith Cayemberg

On 2012-07-15, Dirk Munk <munk@home.nl> wrote:
> Simon Clubley wrote:
>> On 2012-07-15, Dirk Munk <munk@home.nl> wrote:
>>> It is possible to choose between DS10, DS20 and ES40 emulation, but what
>>> is the difference since all three emulations have exactly the same
>>> peripheral limitations?
>>>
>>
>> What are the license requirements for the various systems ?
>
> No requirements, this is the *free* version!
>

I meant the host operating system license requirements, as in the
differences between a ES40 and a DS10 when it comes to the VMS and
layered product license requirements.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2012-07-15, Keith Cayemberg <keith.cayemberg@arcor.de> wrote:
> On Sunday, July 15, 2012 12:56:52 PM UTC+2, Simon Clubley wrote:
>> . . .
>> . . .
>> PuTTY _is_ a VT terminal emulator. I use it on a daily basis at work
>> to talk to VMS systems and run emacs locally in EDT keypad mode.
>> It&#39;s major compatibility annoyance for me (on Linux, I don&#39;t run PuTTY
>> under Windows) is that PF1 through PF4 do not function as such unless
>> the keypad is in application keypad mode. I also have some issues with
>> 8 bit characters not displaying.
>> . . .
>> . . .
>> Simon.
>
>
> I have found that PuTTY v0.61 does not respond appropriately to a $ SET TERM/INQUIRE since it will result in the terminal having a /NOEIGHTBIT attribute even when eightbit is otherwise supported. I find it necessary to do an explicit $ SET TERM/EIGHTBIT to get the Code 1 Page characters of the MCS character set from the keyboard with the needed diacritical characters for European languages.
>

[snip]

Thanks. Since I live in the UK, I am still (mostly) in a 7-bit world so I
have not spent much time trying to get to the bottom of the 8-bit issues in
PuTTY.

BTW, the Google Groups client you are using has started to mangle quoted
text in your replies. I don't know if GG is hiding it from you, but (for
example) in the quote above, "'" has been converted to "&#39;" so it makes
the quoted text harder to read.

I tell you this in case you are unaware of what Google is doing to your
posts.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2012-07-15, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2012-07-15, Dirk Munk <munk@home.nl> wrote:
>> Simon Clubley wrote:
>>> On 2012-07-15, Dirk Munk <munk@home.nl> wrote:
>>>> It is possible to choose between DS10, DS20 and ES40 emulation, but what
>>>> is the difference since all three emulations have exactly the same
>>>> peripheral limitations?
>>>>
>>>
>>> What are the license requirements for the various systems ?
>>
>> No requirements, this is the *free* version!
>>
>
> I meant the host operating system license requirements, as in the
> differences between a ES40 and a DS10 when it comes to the VMS and
> layered product license requirements.
>

Not having a good day. :-) Should be "hosted" above, ie: the operating
system running on the emulated environment.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Simon Clubley mentioned  on 15-7-2012 16:14:
> On 2012-07-15, Dirk Munk <munk@home.nl> wrote:
>> Simon Clubley wrote:
>>> On 2012-07-15, Dirk Munk <munk@home.nl> wrote:
>>>> It is possible to choose between DS10, DS20 and ES40 emulation, but what
>>>> is the difference since all three emulations have exactly the same
>>>> peripheral limitations?
>>>>
>>>
>>> What are the license requirements for the various systems ?
>>
>> No requirements, this is the *free* version!
>>
>
> I meant the host operating system license requirements, as in the
> differences between a ES40 and a DS10 when it comes to the VMS and
> layered product license requirements.
>
> Simon.

As with the other (free or commercial) emulators for VAX and Alpha, that 
depends on your usage. If your usage of the emulator is non-commercial, 
you'd be fine with a VMS hobbyist license on the guest system.

If you want to use the VMS guest in a commercial mode, you'd have to buy 
VMS and LP licenses for the model you are running (license points for 
DS10, DS20, ES40 as with physical systems)

Or, if you are replacing existing DS/ES hardware, you'd buy transfer 
licenses for VMS and LP from HP to legally transfer (not duplicate) your 
existing licenses.

Stromasys (CHARON) negotiated this transfer stuff with HP, but the 
transfer licenses do not claim anywhere that a specific emulator be 
used. Lookup "Stromasys transfer license" on the HP site.

/Wilm

On 2012-07-15, Wilm Boerhout <wboerhout-remove@this-gmail.com> wrote:
>
> If you want to use the VMS guest in a commercial mode, you'd have to buy 
> VMS and LP licenses for the model you are running (license points for 
> DS10, DS20, ES40 as with physical systems)
>
> Or, if you are replacing existing DS/ES hardware, you'd buy transfer 
> licenses for VMS and LP from HP to legally transfer (not duplicate) your 
> existing licenses.
>

Yes, that's what I thought, but it's been a while since I last looked
at VMS licensing. That's why I wondered if one of the reasons for the
multiple emulations was so that existing licenses could be transferred.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Simon Clubley wrote:
> On 2012-07-15, Wilm Boerhout <wboerhout-remove@this-gmail.com> wrote:
>> If you want to use the VMS guest in a commercial mode, you'd have to buy 
>> VMS and LP licenses for the model you are running (license points for 
>> DS10, DS20, ES40 as with physical systems)
>>
>> Or, if you are replacing existing DS/ES hardware, you'd buy transfer 
>> licenses for VMS and LP from HP to legally transfer (not duplicate) your 
>> existing licenses.
>>
> 
> Yes, that's what I thought, but it's been a while since I last looked
> at VMS licensing. That's why I wondered if one of the reasons for the
> multiple emulations was so that existing licenses could be transferred.
> 
> Simon.
> 

The question that occurs to me is, if the emulator is being run on the same host for any 
of the DS10, DS20, or ES40, is there any performance or other difference.  I'm assuming 
not, so I'd also assume you'd just call it a DS10 in order to use the (I'm assuming again) 
least expensive license.

I'm curious as to why there are 3 different models emulated.  They are all EV6, right?

David Froble mentioned  on 16-7-2012 4:21:

[snip]
> The question that occurs to me is, if the emulator is being run on the
> same host for any of the DS10, DS20, or ES40, is there any performance
> or other difference.  I'm assuming not, so I'd also assume you'd just
> call it a DS10 in order to use the (I'm assuming again) least expensive
> license.
[snap]

As a general principle, yes. But depending on the emulator platform 
used, the DS20 may give you 2 CPUs, and the ES40 up to 4. If the 
emulator supports multi-CPU functionality, this will give you more 
processing power (but you need a more expensive VMS license)

/Wilm

Wilm Boerhout wrote:
> David Froble mentioned  on 16-7-2012 4:21:
>
> [snip]
>> The question that occurs to me is, if the emulator is being run on the
>> same host for any of the DS10, DS20, or ES40, is there any performance
>> or other difference.  I'm assuming not, so I'd also assume you'd just
>> call it a DS10 in order to use the (I'm assuming again) least expensive
>> license.
> [snap]
>
> As a general principle, yes. But depending on the emulator platform
> used, the DS20 may give you 2 CPUs, and the ES40 up to 4. If the
> emulator supports multi-CPU functionality, this will give you more
> processing power (but you need a more expensive VMS license)
>
> /Wilm
>
>

You're right, but the free emulator has only one cpu. If you want more 
emulated cpus you will have to buy them.

Thank you for your remarks.=20

On 15-7-2012 12:36, Dirk Munk wrote:>=20
> Nice, but it would even be nicer if we could find some price information=
=20
> about these peripherals.

Extra CPUs, memory and peripheral devices not included in AlphaVM-free are =
offered for an attractive price. Extra  memory and peripheral devices cost =
half of the price available in the commercial version. Please contact us fo=
r a quotation for your required configuration (sales[at]emuvm.com).=20

> =20
> I also have some remarks about the installation manual.
>=20
> There is a PuTTY terminal emulator included with the package. In my=20
> opinion a good VT terminal emulator would be more appropriate, since=20
> many VMS utilities rely on VT escape sequences.

As it was already mentioned in this thread, PuTTY is a terminal emulator. Y=
ou are not limited to PuTTY. You can use your favorite terminal emulator in=
stead. An alternative terminal emulator to launch can be specified in the C=
OM1/COM2 sections of the configuration on Windows. On Linux you just connec=
t any terminal emulator you wish. By default the port numbers are 20000 for=
 COM1 and 20001 for COM2.=20


>=20
> It is possible to choose between DS10, DS20 and ES40 emulation, but what=
=20
> is the difference since all three emulations have exactly the same=20
> peripheral limitations?

The differences between the systems are related to:=20
- Maximal number of CPUs.
- number of PCI buses,
- PCI slot numbering, which is important in some cases (especially for Tru6=
4)
- Alpha marketing models and OpenVMS license units.
The set of peripherals is the same.

>=20
> The default physical address of the emulated ethernet interface is=20
> AA:00:04:00:04:02. This is a DECnet Phase IV compatible address type,=20
> corresponding with DECnet Phase IV address 0.516. In my opinion a=20
> 'neutral' address like 08:00:2B:00:00:01 would have been better.

Yes, it should be safer with  a 'neutral' address in the sense that it does=
 not accidentally coincide with an address on the local network.

>=20
> These is al minimum and maximum Working Set setting, but no mention=20
> about the unit. Is it in bytes, kB, MB or what?

It is in megabytes.=20

>=20
> Is it possible to run two instances of the emulator at the same time on=
=20
> one system? That way it is possible to set up a cluster, and test=20
> cluster aware software.
>=20

It is possible, although there is not much support in the configuration and=
 UI for it.
- You need to run the emulators with configuration files that reside in dif=
ferent directories. The emulator will put some files in the directory of th=
e configuration file (like nvram settings and clock data).=20
- The disk images must be different for all configurations.=20
- By default the CPUs in all instances will get the same affinities. This b=
adly impacts performance. There are yet undocumented options in the configu=
ration file to specify those affinities (not yet in Windows GUI). I will ha=
ve to provide the documentation. =20

Artem  

Artem Alimarin wrote:
> Thank you for your remarks.

And thank you for your reply.

>
> On 15-7-2012 12:36, Dirk Munk wrote:>
>> Nice, but it would even be nicer if we could find some price information
>> about these peripherals.
>
> Extra CPUs, memory and peripheral devices not included in AlphaVM-free are offered for an attractive price. Extra  memory and peripheral devices cost half of the price available in the commercial version. Please contact us for a quotation for your required configuration (sales[at]emuvm.com).
>
>>
>> I also have some remarks about the installation manual.
>>
>> There is a PuTTY terminal emulator included with the package. In my
>> opinion a good VT terminal emulator would be more appropriate, since
>> many VMS utilities rely on VT escape sequences.
>
> As it was already mentioned in this thread, PuTTY is a terminal emulator. You are not limited to PuTTY. You can use your favorite terminal emulator instead. An alternative terminal emulator to launch can be specified in the COM1/COM2 sections of the configuration on Windows. On Linux you just connect any terminal emulator you wish. By default the port numbers are 20000 for COM1 and 20001 for COM2.
>

Of courese I'm aware that PuTTY is a terminal emulator. Excluding the 
rather different VT52, Digital made a whole range of related terminals, 
from the VT100 to the VT525. The VT100 was the base, and many emulators 
claim VT100 compatibility. In reality that is often a very basic 
compatibility, and many VMS utilities require more than basic compatibility.


>
>>
>> It is possible to choose between DS10, DS20 and ES40 emulation, but what
>> is the difference since all three emulations have exactly the same
>> peripheral limitations?
>
> The differences between the systems are related to:
> - Maximal number of CPUs.
> - number of PCI buses,
> - PCI slot numbering, which is important in some cases (especially for Tru64)
> - Alpha marketing models and OpenVMS license units.
> The set of peripherals is the same.

I understand the CPUs and license part, but does the emulator also 
provide virtual PCI buses?

>
>>
>> The default physical address of the emulated ethernet interface is
>> AA:00:04:00:04:02. This is a DECnet Phase IV compatible address type,
>> corresponding with DECnet Phase IV address 0.516. In my opinion a
>> 'neutral' address like 08:00:2B:00:00:01 would have been better.
>
> Yes, it should be safer with  a 'neutral' address in the sense that it does not accidentally coincide with an address on the local network.
>

It is a bit more of a problem. Other DECnet PhaseIV devices (like 
routers) may conclude that such an emulated Alpha is running DECnet 
PhaseIV even if DECnet is not running at all because of the AA:00:04 mac 
address.

>>
>> These is al minimum and maximum Working Set setting, but no mention
>> about the unit. Is it in bytes, kB, MB or what?
>
> It is in megabytes.
>
>>
>> Is it possible to run two instances of the emulator at the same time on
>> one system? That way it is possible to set up a cluster, and test
>> cluster aware software.
>>
>
> It is possible, although there is not much support in the configuration and UI for it.
> - You need to run the emulators with configuration files that reside in different directories. The emulator will put some files in the directory of the configuration file (like nvram settings and clock data).

Nice, in VMS terms a kind of sys$common and sys$specific set up :-) .

> - The disk images must be different for all configurations.

That is a bit surprising. The manual states that shared access of a disk 
image is possible. I had hope that the standard VMS locking mechanism 
would be sufficient for the shared access from two emulators running 
OpenVMS. Wouldn't it be cool to run cluster config for a shared system 
disk on one emulator, and then booting OpenVMS on an other emulator and 
starting a OpenVMS cluster on a laptop this way?

> - By default the CPUs in all instances will get the same affinities. This badly impacts performance. There are yet undocumented options in the configuration file to specify those affinities (not yet in Windows GUI). I will have to provide the documentation.
>
> Artem
>

On 16-7-2012 23:08, Dirk Munk wrote:> Of courese I'm aware that PuTTY is a =
terminal emulator. Excluding the=20
> rather different VT52, Digital made a whole range of related terminals,=
=20
> from the VT100 to the VT525. The VT100 was the base, and many emulators=
=20
> claim VT100 compatibility. In reality that is often a very basic=20
> compatibility, and many VMS utilities require more than basic=20
> compatibility.

In this thread there were already some remarks about the quality of VT100  =
emulation. For what I do PuTTY is enough, but I am well aware that people w=
ant their favorite VT emulators. Therefore AlphaVM allows to connect a cust=
om VT emulator.=20

> I understand the CPUs and license part, but does the emulator also=20
> provide virtual PCI buses?

The emulator emulates the whole Alpha system. This also includes PCI buses.=
 For instance, ES40 has 2 top-level PCI buses (hoses) provided by the Tsuna=
mi chipset. They are completely virtual: the emulated PCI buses allow to pl=
ug emulated/virtual PCI controllers. Currently there are SCSI and Ethernet =
controllers plugged. The emulator does not currently provide a mapping betw=
een the host and the guest PCI slots (which is also known as PCI pass throu=
gh).  =20

> It is a bit more of a problem. Other DECnet PhaseIV devices (like=20
> routers) may conclude that such an emulated Alpha is running DECnet=20
> PhaseIV even if DECnet is not running at all because of the AA:00:04 mac=
=20
> address.

Ok, I agree with you. I will change the defaults in the next release.=20

>=20
> Nice, in VMS terms a kind of sys$common and sys$specific set up :-) .
>=20
>> - The disk images must be different for all configurations.
>=20
> That is a bit surprising. The manual states that shared access of a disk=
=20
> image is possible. I had hope that the standard VMS locking mechanism=20
> would be sufficient for the shared access from two emulators running=20
> OpenVMS. Wouldn't it be cool to run cluster config for a shared system=20
> disk on one emulator, and then booting OpenVMS on an other emulator and=
=20
> starting a OpenVMS cluster on a laptop this way?

Yes, the sharing option is there to allow shared disks. You are absolutely =
right, such disks can be shared. What I meant, is that the disks are not sh=
ared per accident, in an uncontrolled way. Therefore the shared access opti=
on is by default off.=20

Artem  

artem.alimarin@gmail.com wrote:
> On 16-7-2012 23:08, Dirk Munk wrote:> Of courese I'm aware that PuTTY is a terminal emulator. Excluding the
>> rather different VT52, Digital made a whole range of related terminals,
>> from the VT100 to the VT525. The VT100 was the base, and many emulators
>> claim VT100 compatibility. In reality that is often a very basic
>> compatibility, and many VMS utilities require more than basic
>> compatibility.
>
> In this thread there were already some remarks about the quality of VT100  emulation. For what I do PuTTY is enough, but I am well aware that people want their favorite VT emulators. Therefore AlphaVM allows to connect a custom VT emulator.
>
>> I understand the CPUs and license part, but does the emulator also
>> provide virtual PCI buses?
>
> The emulator emulates the whole Alpha system. This also includes PCI buses. For instance, ES40 has 2 top-level PCI buses (hoses) provided by the Tsunami chipset. They are completely virtual: the emulated PCI buses allow to plug emulated/virtual PCI controllers. Currently there are SCSI and Ethernet controllers plugged. The emulator does not currently provide a mapping between the host and the guest PCI slots (which is also known as PCI pass through).
>
>> It is a bit more of a problem. Other DECnet PhaseIV devices (like
>> routers) may conclude that such an emulated Alpha is running DECnet
>> PhaseIV even if DECnet is not running at all because of the AA:00:04 mac
>> address.
>
> Ok, I agree with you. I will change the defaults in the next release.

Good. The 08-00-2B mac address series I suggested were used in older DEC 
ethernet interfaces. It is less likely that many of these MAC addresses 
are still in use, and it is classic DEC at the same time.

>
>>
>> Nice, in VMS terms a kind of sys$common and sys$specific set up :-) .
>>
>>> - The disk images must be different for all configurations.
>>
>> That is a bit surprising. The manual states that shared access of a disk
>> image is possible. I had hope that the standard VMS locking mechanism
>> would be sufficient for the shared access from two emulators running
>> OpenVMS. Wouldn't it be cool to run cluster config for a shared system
>> disk on one emulator, and then booting OpenVMS on an other emulator and
>> starting a OpenVMS cluster on a laptop this way?
>
> Yes, the sharing option is there to allow shared disks. You are absolutely right, such disks can be shared. What I meant, is that the disks are not shared per accident, in an uncontrolled way. Therefore the shared access option is by default off.
>

Ah, that is very nice to hear. I'm used to work with SAN storage, so I'm 
well aware that you can never connect a disk/lun to two systems that are 
not in a cluster or another type of well regulated shared storage access.

> Artem
>

On Tuesday, July 17, 2012 11:51:56 AM UTC+2, Dirk Munk wrote:
> Ah, that is very nice to hear. I'm used to work with SAN storage, so I'm 
> well aware that you can never connect a disk/lun to two systems that are 
> not in a cluster or another type of well regulated shared storage access.

It is also possible to share read-only disks, like iso images. For instance, it is possible to install two instances from the same iso at the same time. 

artem.alimarin@gmail.com wrote:
> On Tuesday, July 17, 2012 11:51:56 AM UTC+2, Dirk Munk wrote:
>> Ah, that is very nice to hear. I'm used to work with SAN storage, so I'm
>> well aware that you can never connect a disk/lun to two systems that are
>> not in a cluster or another type of well regulated shared storage access.
>
> It is also possible to share read-only disks, like iso images. For instance, it is possible to install two instances from the same iso at the same time.
>

Yes of course. But then the disk should be read-only for all instances. 
I have seen system managers trying to use a disk read-only when another 
system had the disk mounted for read-write. The system with the 
read-only access then crashed because the contents of the disk had 
changed compared to the information about the disk it had in memory.

On Tuesday, July 17, 2012 1:24:13 PM UTC+2, Dirk Munk wrote:
> artem.alimarin wrote:
> > On Tuesday, July 17, 2012 11:51:56 AM UTC+2, Dirk Munk wrote:
> >> Ah, that is very nice to hear. I'm used to work with SAN storage, so I'm
> >> well aware that you can never connect a disk/lun to two systems that are
> >> not in a cluster or another type of well regulated shared storage access.
> >
> > It is also possible to share read-only disks, like iso images. For instance, it is possible to install two instances from the same iso at the same time.
> >
> 
> Yes of course. But then the disk should be read-only for all instances. 
> I have seen system managers trying to use a disk read-only when another 
> system had the disk mounted for read-write. The system with the 
> read-only access then crashed because the contents of the disk had 
> changed compared to the information about the disk it had in memory.

I used such a configuration without problems. The disk containing program code on the development system was also mounted on the test system with /NOWRITE and /NOCACHE. This has never led to problems to my knowledge. Of course other situations may differ.

Bart

In article <648379d7-055e-4c98-b763-bf8d14cd20ac@googlegroups.com>, Bart Zorn <bart.zorn@gmail.com> writes:
> On Tuesday, July 17, 2012 1:24:13 PM UTC+2, Dirk Munk wrote:
>> 
>> Yes of course. But then the disk should be read-only for all instances. 
>> I have seen system managers trying to use a disk read-only when another 
>> system had the disk mounted for read-write. The system with the 
>> read-only access then crashed because the contents of the disk had 
>> changed compared to the information about the disk it had in memory.
> 
> I used such a configuration without problems. The disk containing program code on the development system was also mounted on the test system with /NOWRITE and /NOCACHE. This has never led to problems to my knowledge. Of course other situations may differ.

   Before VMSclusters, you could share a MASSBUS disk between two VAXen
   under VMS 3, by mounting it /readonly on at least one and /nochache
   on both.

   Sometime after the introduction of LAVC, this was changed to sharing
   it mounted writable and cached if the two systems were members of
   the same cluster.

   I had no actual experience clustering systems with MASSBUS adapters.

On Wed, 18 Jul 2012 08:59:39 -0600, Bob Koehler wrote:

> In article <648379d7-055e-4c98-b763-bf8d14cd20ac@googlegroups.com>, Bart
> Zorn <bart.zorn@gmail.com> writes:
>> On Tuesday, July 17, 2012 1:24:13 PM UTC+2, Dirk Munk wrote:
>>> 
>>> Yes of course. But then the disk should be read-only for all
>>> instances.
>>> I have seen system managers trying to use a disk read-only when
>>> another system had the disk mounted for read-write. The system with
>>> the read-only access then crashed because the contents of the disk had
>>> changed compared to the information about the disk it had in memory.
>> 
>> I used such a configuration without problems. The disk containing
>> program code on the development system was also mounted on the test
>> system with /NOWRITE and /NOCACHE. This has never led to problems to my
>> knowledge. Of course other situations may differ.
> 
>    Before VMSclusters, you could share a MASSBUS disk between two VAXen
>    under VMS 3, by mounting it /readonly on at least one and /nochache
>    on both.

I did this with V3.1 to offload compiler batch queues to another system. 
I don't remember all the gory details but once done the listings and .EXEs 
got copied back to the correct destination on the first machine.

We didn't have any network cards or DECnet at that point

-- 
Paul Sture

On 2012-07-15 14:23, Keith Cayemberg wrote:
> On Sunday, July 15, 2012 12:56:52 PM UTC+2, Simon Clubley wrote:
>> . . .
>> . . .
>> PuTTY _is_ a VT terminal emulator. I use it on a daily basis at work
>> to talk to VMS systems and run emacs locally in EDT keypad mode.
>> It's major compatibility annoyance for me (on Linux, I don't run PuTTY
>> under Windows) is that PF1 through PF4 do not function as such unless
>> the keypad is in application keypad mode. I also have some issues with
>> 8 bit characters not displaying.
>> . . .
>> . . .
>> Simon.
>
>
> I have found that PuTTY v0.61 does not respond appropriately to a $ SET TERM/INQUIRE since it will result in the terminal having a /NOEIGHTBIT attribute even when eightbit is otherwise supported. I find it necessary to do an explicit $ SET TERM/EIGHTBIT to get the Code 1 Page characters of the MCS character set from the keyboard with the needed diacritical characters for European languages.

Hum. I should re-check VMS here, but I believe /EIGHTBIT is actually an 
indication if the terminal will do (and understand) 8-bit control 
sequences or not. That is, if CSI will actually be done as CSI, or ESC + 
"[" for example.
Thus, you should check the putty settings for control sequences if you 
want to get that right. It has nothing to do with if the terminal was 
going 8-bit clean for printable characters or not.

But I might be confused... (I'll try and check this up...)

By the way, I normally run the "latest" release, and not the "stable", 
for what it is worth. Last I checked, the "stable" version was a lot 
more incompatible.

> This was a problem whether or not I used a standard German USB PC keyboard or a LK461-AG connected to a PS2 keyboard port.

Of course, since it has nothing to do with the keyboard as such.

> I have done a considerable amount of configuration testing get an exceptable level of VT compatibilty out of PuTTY, since our current customer has standardized on PuTTY.

I've tried a number of terminal emulators, and xterm is the only one I 
haven't found annoying bugs in so far. But I'm willing to try yet 
another, if anyone suggest something.
I know of one bug in putty that annoys me, but that has to do with 
cursor addressing and wrapping, which is incompatible with a VT terminal.

> For a font I found the line drawing characters coming with Window's Courier New 14 pt combined with "use Unicode line drawing code points" setting to be a good setting for VMS displays such as a $ MONITOR SYSTEM.

I definitely try to stay away from anything even breathing Unicode, 
since that normally means things will not work right.

> For remote character set I have DEC-MCS, to accurately portray what OpenVMS recognizes by default.

Not sure I understood what you said here.

> For the Keyboard Function Keys and Keypad settings the ESC[n~ setting is surprisingly working best for me, not the Xterm, VT400 or VT100+ settings.

I guess I should fire up putty and check how things work. I'm just not 
sitting at a computer with a reasonable keyboard right now, so I 
can't... (Laptop keyboards are key deficient...)

	Johnny

In article <jv8hjr$ggi$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> 
> Hum. I should re-check VMS here, but I believe /EIGHTBIT is actually an 
> indication if the terminal will do (and understand) 8-bit control 
> sequences or not. That is, if CSI will actually be done as CSI, or ESC + 
> "[" for example.
> Thus, you should check the putty settings for control sequences if you 
> want to get that right. It has nothing to do with if the terminal was 
> going 8-bit clean for printable characters or not.

   I've run into the same issue.  Without an explicit /eightbit putty
   display's DEC MCS copyright character as a ".".  With it, it displays
   as a copyright character.

   Shows up every time I start Notes on eisner or deathrow.

On 2012-07-31 17:04, Bob Koehler wrote:
> In article <jv8hjr$ggi$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>
>> Hum. I should re-check VMS here, but I believe /EIGHTBIT is actually an
>> indication if the terminal will do (and understand) 8-bit control
>> sequences or not. That is, if CSI will actually be done as CSI, or ESC +
>> "[" for example.
>> Thus, you should check the putty settings for control sequences if you
>> want to get that right. It has nothing to do with if the terminal was
>> going 8-bit clean for printable characters or not.
>
>     I've run into the same issue.  Without an explicit /eightbit putty
>     display's DEC MCS copyright character as a ".".  With it, it displays
>     as a copyright character.
>
>     Shows up every time I start Notes on eisner or deathrow.

I'm probably wrong and confused then. Mixing things with how RSX does, I 
suspect. That is my most common failure mode with VMS. :-)

Does VMS somehow keep apart if the terminal understands the 8-bit 
versions of control sequences in another attribute then, or does it not 
keep that around at all?

Just checked with xterm, and it identifies as a vt200 series, but I do 
not automatically get eightbit there either.

How would /INQUIRE actually be able to figure out that it should set 
/EIGHTBIT? putty or not...

	Johnny

In article <jv8pnr$m6e$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> 
> Does VMS somehow keep apart if the terminal understands the 8-bit 
> versions of control sequences in another attribute then, or does it not 
> keep that around at all?

   My understanding is that /eightbit tells VMS whether the hardware
   actually understands 8 bits, separately from them being present
   on a serial line.

   That is 8 bit bytes on a serial line doesn't guarantee the hardware
   knows what to do with bytes above 255.  TELNET and ssh may always
   transfer 8 bit bytes, but the end device may still have the same
   issue.

   I've never had a problem with /inquire getting 8 bit wrong on serial
   lines to real VTs.  But I might have just been lucky.  I might have
   the terminal settings defaulted to eightbit.

On 2012-07-31 19:20:41 +0000, Bob Koehler said:

>    That is 8 bit bytes on a serial line doesn't guarantee the hardware
>    knows what to do with bytes above 255.

The eight-bit setting doesn't guarantee which characters the (usually 
terminal) device will present to the end-user when an application 
transmits bytes in the eight-bit 128 to 255 range, either.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-07-31 21:20, Bob Koehler wrote:
> In article <jv8pnr$m6e$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>
>> Does VMS somehow keep apart if the terminal understands the 8-bit
>> versions of control sequences in another attribute then, or does it not
>> keep that around at all?
>
>     My understanding is that /eightbit tells VMS whether the hardware
>     actually understands 8 bits, separately from them being present
>     on a serial line.

Hmm. I guess that is the case. Unless /eightbit is set, it seems to 
strip the eighth bit.
In RSX, you actually have two attributes related here.
You have the CHAR_LENGTH, which can be 7 or 8, and tells what length you 
characters are. If it's 7, the high bit gets stripped.
Then you have EBC, which tells if your terminal do eight bit control 
characters, or if you should do the 7-bit equivalents.
Of course, having CHAR_LENGTH=7 and EBC set makes little sense, but all 
three other combinations are valid and meaningful.

>     That is 8 bit bytes on a serial line doesn't guarantee the hardware
>     knows what to do with bytes above 255.  TELNET and ssh may always
>     transfer 8 bit bytes, but the end device may still have the same
>     issue.

Above 127, I assume you mean. :-)
But apart from that, yes indeed. The attribute should reflect the 
terminal at the other end, not the intermediate transport (except if the 
intermediate transport strips data then this becomes relevant and should 
be reflected anyway).

>     I've never had a problem with /inquire getting 8 bit wrong on serial
>     lines to real VTs.  But I might have just been lucky.  I might have
>     the terminal settings defaulted to eightbit.

That might be, because I cannot figure out how VMS should know if it 
should set eightbit or not based on the response of the terminal to a DA1.

	Johnny

On 2012-07-31 20:33, Stephen Hoffman wrote:
> On 2012-07-31 19:20:41 +0000, Bob Koehler said:
>
>>    That is 8 bit bytes on a serial line doesn't guarantee the hardware
>>    knows what to do with bytes above 255.
>
> The eight-bit setting doesn't guarantee which characters the (usually
> terminal) device will present to the end-user when an application
> transmits bytes in the eight-bit 128 to 255 range, either.

It don't guarantee which characters the terminal will present to the end 
user for bytes in the range 0-127 either. You can select any character 
set in G0 as well, and also tell that you should not even use G0 for 
characters in the range 0-127.

All you actually know is that characters 0-127 will display whatever is 
in GL, while 128-255 will display whatever is in GR. GL and GR are in 
turn both mapped to G0, G1, G2 or G3, and G0-3 are in turn mapped to a 
character set.

See http://vt100.net/docs/vt510-rm/LS for a start.

Trivia question: which function existed in the VT100 series, but was 
removed in the VT200 series and newer, only to make a return in the 
VT500 series? :-)

	Johnny

On 2012-07-31 20:14:53 +0000, Johnny Billquist said:

> 
> Right. And there is no attribute in the response to DA1 or DA2 which 
> tells that you should be doing Eightbit.
> ...
> 
> I have done way too many things with terminals and drivers at this 
> point. I know the ins and outs of a lot of weird stuff related to 
> terminals, serial communication, and what not. Go ahead, just ask me... 
> :-)

Most (sane) folks used terminal libraries, whether that was the aptly 
named curses library or (on Unix) ncurses, or the OpenVMS SMG RTL, or 
products including FMS or TDMS.  (And FWIW, I have some code buried in 
NEWUSER <http://labs.hoffmanlabs.com/node/1260> that reads a sequence 
out of the SMG dictionary, rather than hard-coding it.)

As for your question, and this going from memory...

The DA1 response tells the host if it's eight-bit or not, and in the 
first "useful" byte of the response.

Here's a DA1 response for one variety of VT510:

CSI ? 64; 1; 2; 7; 8; 9; 15; 18; 21; 44; 45; 46 c

That (eight-bit) response shows an ASCII 4 (decimal 64) in the third 
character position, which is (duh) level 4.  Level 2 and up are 
eight-bit terminal devices, but can do also freely accept seven-bit in 
its sted.  OpenVMS refers to these as DECCRT2 and up; DECCRT2 or better 
in a $getdvi response or if you see that level or better in the DA1 
response, and you're good to use eight-bit, though I'd (also) expect to 
see code honor the /EIGHTBIT setting.

Level 1 and VT52 are seven-bit; DECCRT1, and no DECCRT1  No eight-bit there.

What SET TERMINAL /INQUIRE does with the settings here, I don't know 
off-hand.  Some of the terminal-related documentation (hardware and 
OpenVMS) is definitely somewhat confusing.  And operating with various 
terminals usually involves trial-and-error; the usual approach for 
figuring out what the hardware really does, and where the documentation 
disagrees with reality.


Resources:

http://vt100.net/docs/vt510-rm/chapter4#S4.4.1
http://vt100.net/docs/vt510-rm/DA1
$getdvi[w] DVI$_TT_EIGHTBIT, DVI$_TT_DECCRT1, 2, 3, 4, 5
Related DEC STDs 107, 110, 111 and...?




-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-07-31 23:34, Stephen Hoffman wrote:
> On 2012-07-31 20:14:53 +0000, Johnny Billquist said:
>
>>
>> Right. And there is no attribute in the response to DA1 or DA2 which
>> tells that you should be doing Eightbit.
>> ...
>>
>> I have done way too many things with terminals and drivers at this
>> point. I know the ins and outs of a lot of weird stuff related to
>> terminals, serial communication, and what not. Go ahead, just ask
>> me... :-)
>
> Most (sane) folks used terminal libraries, whether that was the aptly
> named curses library or (on Unix) ncurses, or the OpenVMS SMG RTL, or
> products including FMS or TDMS.  (And FWIW, I have some code buried in
> NEWUSER <http://labs.hoffmanlabs.com/node/1260> that reads a sequence
> out of the SMG dictionary, rather than hard-coding it.)

Never had the luxury of that in RSX... :-)
Well, I do have FMS, but anyway, I've done a gazillion things on my own 
without libraries for various reasons...

> As for your question, and this going from memory...
>
> The DA1 response tells the host if it's eight-bit or not, and in the
> first "useful" byte of the response.
>
> Here's a DA1 response for one variety of VT510:
>
> CSI ? 64; 1; 2; 7; 8; 9; 15; 18; 21; 44; 45; 46 c
>
> That (eight-bit) response shows an ASCII 4 (decimal 64) in the third
> character position, which is (duh) level 4.  Level 2 and up are
> eight-bit terminal devices, but can do also freely accept seven-bit in
> its sted.  OpenVMS refers to these as DECCRT2 and up; DECCRT2 or better
> in a $getdvi response or if you see that level or better in the DA1
> response, and you're good to use eight-bit, though I'd (also) expect to
> see code honor the /EIGHTBIT setting.

Well, no. This could be either a 7-bit or an 8-bit response. The 
terminal will for CSI send either the CSI character (0233) or ESC [. If 
it's ESC [, I would call it a 7-bit response. Is your definition 
different? And the problem is that which it will send depends on a 
setting in your setup. You can set it to use 7-bit or 8-bit controls. 
The manuals for the terminals always only says "CSI", and then CSI can 
be transmitted two ways. This is documented in another section of the 
manual.

(By the way, it does not show an ASCII 4 in the third character 
position. This is a common error done by many. It actually sends '6', 
followed by '4', followed by ';'. Also, an ASCII 4 would be decimal 52, 
*octal* 64.)

But you are essentially saying that anything reporting to be level 2 or 
above could be assumed to be eightbit. But what if you have actually set 
your VT510 to run with 7 data bits? The response to DA1 will be the 
same, but in truth, this will not be a 8-bit capable terminal in this 
case. eightbit should not be set. But there is no way to tell. It would 
not understand if you sent a CSI (0233). The same is most likely true if 
you set it to use 7-bit controls explicitly, even if the terminal is set 
to use 8 data bits. And it will definitely not send CSI in that case, so 
even though you know it's a level 2 or better terminal, it will not be 
sending you 8-bit control characters.

> Level 1 and VT52 are seven-bit; DECCRT1, and no DECCRT1  No eight-bit
> there.

Indeed. But even with level 2 and above, the terminal does not 
necessarily do 8 bit stuff. You can turn on NRCS, 7-bit controls, 7 bit 
word size, set the serial communication to do 7 bits with space parity, 
and god knows what more...

So, just because the terminal is conforming to level 2 or above does not 
mean that the terminal is actually currently set up in a way that allows 
it to do eightbit.

> What SET TERMINAL /INQUIRE does with the settings here, I don't know
> off-hand.  Some of the terminal-related documentation (hardware and
> OpenVMS) is definitely somewhat confusing.  And operating with various
> terminals usually involves trial-and-error; the usual approach for
> figuring out what the hardware really does, and where the documentation
> disagrees with reality.

I won't argue on that one. :-)

> Resources:
>
> http://vt100.net/docs/vt510-rm/chapter4#S4.4.1
> http://vt100.net/docs/vt510-rm/DA1
> $getdvi[w] DVI$_TT_EIGHTBIT, DVI$_TT_DECCRT1, 2, 3, 4, 5
> Related DEC STDs 107, 110, 111 and...?

By the way, I should test this on a real VT510, but I find it funny that 
a VT510 should report itself as a VT400 series device. The VT520/525 
will respond with a 65 as the first value, which is more logical. My 
first reaction is that the manual is wrong, but it might be an actual 
difference between the VT510 and VT520.

Anyway, the table is silly, but still interesting. It's a plain ASCII 
number, but looking at the VT200 and newer, the values are actually the 
octal for the number of the ASCII character of the first digit of the 
terminal series...
Thus:
62 - VT200 (62 being the octal value for the ASCII character "2")
63 - VT300
64 - VT400
65 - VT500 (atleast VT520/525)

However, the VT100 does not report 61, but instead actually reports as 
1. And the VT102 says 6. It's all rather messy, unfortunately.

By the way, the DA1 responses are very confusing. For some things, like 
the number of columns, it reports the actual current setting, while for 
others, like NRCS, it reports that the terminal have the capability, but 
you don't know if it is currently on or not. Eightbit also falls into 
that category. You can see that the terminal is a level 2 or better 
device, but you can't tell if 7-bit control is on, except that if you 
actually get a CSI (0233), then obviously 8-bit control is on and working.

So, how would VMS be able to know from DA1 if eightbit should be on? It 
should, after all, reflect the current settings in the terminal, and not 
the potential capability, no?

	Johnny

On 2012-08-01 01:16, Johnny Billquist wrote:
> By the way, the DA1 responses are very confusing. For some things, like
> the number of columns, it reports the actual current setting, while for
> others, like NRCS, it reports that the terminal have the capability, but
> you don't know if it is currently on or not. Eightbit also falls into
> that category. You can see that the terminal is a level 2 or better
> device, but you can't tell if 7-bit control is on, except that if you
> actually get a CSI (0233), then obviously 8-bit control is on and working.
>
> So, how would VMS be able to know from DA1 if eightbit should be on? It
> should, after all, reflect the current settings in the terminal, and not
> the potential capability, no?

Oh darn. Here I go again correcting myself.
DA1 will actually only report capabilities, not actual current settings.
Thus, it always reports 1 as one of the attributes (132 columns) on a 
DEC terminal, even if it is in 80 column mode, as it still have the 
capability of switching to 132 columns.
DA1 is really not useful for finding out anything changeable about a 
terminal, but really is just information on what you potentially can do.

	Johnny

On 2012-07-31 23:16:10 +0000, Johnny Billquist said:
> 
> So, how would VMS be able to know from DA1 if eightbit should be on? It 
> should, after all, reflect the current settings in the terminal, and 
> not the potential capability, no?

If the terminal is set to respond as seven-bit, then it's a seven-bit device.

The DA1 response cited was from the VT510 manual.

And I've only just realized how very, very much I do not care about 
this topic and about terminal and escape sequences, and how much time 
I've already spent digging details out of my memory and out of the 
existing documentation.  Digging into the old DEC Standards to confirm 
some details just isn't going to happen.    This discussion certainly 
has served to refresh how much I once despised this user interface.  
From back when I had to deal with this stuff more often.

Now?  The difference between seven- and eight-bit is irrelevent for the 
vast majority of cases, many applications are probably forever 
seven-bit, and the applications and tools that are still using the 
terminal interfaces directly are most charitably referred to as being 
"not mainstream" or "specialized users".

Here?  Send the terminal seven-bit and move on.  Or better still, use a 
library, and let that deal with this mess.

If you're curious about any of this, by all means, have at the docs, 
and run the tests.



-- 
Pure Personal Opinion | HoffmanLabs LLC

On 7/31/2012 7:34 PM, Stephen Hoffman wrote:
> And I've only just realized how very, very much I do not care about this
> topic and about terminal and escape sequences, and how much time I've
> already spent digging details out of my memory and out of the existing
> documentation.
>
> Now?  The difference between seven- and eight-bit is irrelevent for the
> vast majority of cases, many applications are probably forever
> seven-bit, and the applications and tools that are still using the
> terminal interfaces directly are most charitably referred to as being
> "not mainstream" or "specialized users".
>
> Here?  Send the terminal seven-bit and move on.  Or better still, use a
> library, and let that deal with this mess.

Even more fun is trying to correctly implement the terminfo/termcap API 
on VMS.

There is absolutely no documentation for many of the attributes set in 
that database for the VT1xx terminals on *nix systems.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only

On 2012-08-01 02:34, Stephen Hoffman wrote:
> On 2012-07-31 23:16:10 +0000, Johnny Billquist said:
>>
>> So, how would VMS be able to know from DA1 if eightbit should be on?
>> It should, after all, reflect the current settings in the terminal,
>> and not the potential capability, no?
>
> If the terminal is set to respond as seven-bit, then it's a seven-bit
> device.

My point was that there is no response "seven bit". And believe me, I've 
read the manuals backwards and forwards plenty of times.
I was curious on how people expected VMS to be able to set eightbit, 
based on the information in DA1. Maybe something clever that I had 
missed, but based on your responses, as well as the fact that VMS do not 
set eightbit even if I have all the capabilities set correctly when I 
test seems to prove that VMS does indeed not do this, as it can't.

> The DA1 response cited was from the VT510 manual.

I know.

> And I've only just realized how very, very much I do not care about this
> topic and about terminal and escape sequences, and how much time I've
> already spent digging details out of my memory and out of the existing
> documentation.  Digging into the old DEC Standards to confirm some
> details just isn't going to happen.    This discussion certainly has
> served to refresh how much I once despised this user interface. From
> back when I had to deal with this stuff more often.

Ok. I get the message. :-)
Please do not feel obliged to answer and figure out any more. After all, 
it wasn't even you who complained. Sorry if I "forced" you to look at 
stuff you don't want to be reminded of.
I was curious and asked a question based on the original "complaint", 
since as far as I can tell, VMS does as much as you could expect it to do.

If someone else can show VMS doing more, and even better, under which 
circumstances, I'm curious to look at how it is done. The contents of 
DA1 does not provide enough information, with the possible exception 
that if you get a CSI as the eight bit character, that is a pretty good 
indication that maybe eightbit should be set. (That bit of information 
is, by the way, what RSX use to set EBC, which is actually exactly how 
much it really tells.)

All the rest I've already run over in my past messages here.

And yes, me personally, I enjoy hacking on terminals, and find the 
interface pretty fun to play with. As well as serial communication in 
general.

	Johnny

On 8/1/2012 5:18 AM, Johnny Billquist wrote:
>
> My point was that there is no response "seven bit". And believe me, I've
> read the manuals backwards and forwards plenty of times.
> I was curious on how people expected VMS to be able to set eightbit,
> based on the information in DA1. Maybe something clever that I had
> missed, but based on your responses, as well as the fact that VMS do not
> set eightbit even if I have all the capabilities set correctly when I
> test seems to prove that VMS does indeed not do this, as it can't.

VMS only seems to be able designed to detect a specific set of VT series 
terminals that were sold by them or the company that now sells them.  In 
some cases it can get the geometry of the terminal, in others it can not.

SSH passes a terminal identification string and the geometry, and maybe 
some other attributes to the end system.

Putty lies by default and tells the target system it is an xterm, even 
though by default it uses a reversed foreground and background.

This lie means that the default color output on Linux can be a bit 
unreadable on Putty.

> If someone else can show VMS doing more, and even better, under which
> circumstances, I'm curious to look at how it is done. The contents of
> DA1 does not provide enough information, with the possible exception
> that if you get a CSI as the eight bit character, that is a pretty good
> indication that maybe eightbit should be set. (That bit of information
> is, by the way, what RSX use to set EBC, which is actually exactly how
> much it really tells.)

Unfortunately it does not, so creating an algorithm to do so is up to 
someone else.

The only reliable way that I can see to get the current terminal 
geometry is to move the cursor to various locations and then read it 
back.  And with "linked" screens active, even that can return false 
information.  That is also something needed to detect broken wrap.

And there are a number of terminal properties that an application would 
be interested in that do not seem to be supported by the 
terminfo/termcap database or ncurses.

Set term/inquire has some unfortunate side effects, such as sometimes 
setting the terminal geometry back to 24 * 80, depending on what it finds.

The Curses library in VMS is broken.  It does not matter what terminal 
type you tell it to return values for, it always returns the values for 
a VT100.  So even changing the terminal settings will not affect a C 
program that uses it.

In the GNV sourceforge CVS directory for the VMS (gnu_vms subtree) 
specific changes to BASH-4.2 is a replacement curses implementation that 
actually reads the VMS terminal database and has an alias for xterm, and 
possibly some other models.

I did what I could, but many of the termcap/terminfo settings are not 
documented at all.

Linux does not seem to even attempt to auto-detect a terminal type.

> All the rest I've already run over in my past messages here.
>
> And yes, me personally, I enjoy hacking on terminals, and find the
> interface pretty fun to play with. As well as serial communication in
> general.

Serial communications is still used for many consoles and debugging or 
diagnostic ports.  The terminal server market is apparently alive and well.

One of the complaints about the current generation of low cost tablets 
is that there is not a serial port that would allow technicians to use 
them instead of carrying around a laptop.  In some cases an application 
vendor is making a proprietary cable for serial communications.  But a 
general solution is not available.

The D-Rats Amateur radio system uses serial communications, but can not 
be used with either a Android tablet or iPad/iPod for that reason.

The future Microsoft Surface tablet supports a serial port through USB 
and may be able to capture a bit of that market that has been written 
off by others.  How big is it?  I do not know.

It looks like some Android hardware may supports host mode, which is 
required for connecting to a serial port.  Software support is limited 
to a number of Google approved devices, which currently does not appear 
to support a serial port.

Regards,
-John

On 2012-08-01 14:53, John E. Malmberg wrote:
> On 8/1/2012 5:18 AM, Johnny Billquist wrote:
>>
>> My point was that there is no response "seven bit". And believe me, I've
>> read the manuals backwards and forwards plenty of times.
>> I was curious on how people expected VMS to be able to set eightbit,
>> based on the information in DA1. Maybe something clever that I had
>> missed, but based on your responses, as well as the fact that VMS do not
>> set eightbit even if I have all the capabilities set correctly when I
>> test seems to prove that VMS does indeed not do this, as it can't.
>
> VMS only seems to be able designed to detect a specific set of VT series
> terminals that were sold by them or the company that now sells them.  In
> some cases it can get the geometry of the terminal, in others it can not.

Well, yes and no. VMS does not detect specific terminals, but only uses 
the somewhat generic responses from the DA1 escape sequence response. 
Geometry is basically guessed (well, pretty much assumed) to be 24x80, 
since almost all text terminals have that geometry.

> SSH passes a terminal identification string and the geometry, and maybe
> some other attributes to the end system.

It does, when the receiving system can understand that. However, that 
does not change that the actual terminal emulation you are running, in 
which you are then running ssh, also might respond to DA1. And I suspect 
that VMS looks more at that than what terminal string might be passed in 
the ssh protocol.

> Putty lies by default and tells the target system it is an xterm, even
> though by default it uses a reversed foreground and background.

VMS does not use that, as far as I know. VMS systems usually do a set 
term/inquire, which requests an identification from the terminal. The 
responses to this are not strings in the format you might be thinking.

> This lie means that the default color output on Linux can be a bit
> unreadable on Putty.

It is not necessarily lying. However, the whole thing is rather more 
complicated, and people often do not understand how things actually work 
together.

"xterm" does not even imply that color is possible, or how it is 
controlled. Unix traditionally have used the TERM variable to figure out 
the capabilities of the terminal, and there have never been a reliable 
way of automatically set the TERM variable correctly, nor are there any 
absolutely canonical list of names to use for the TERM value to indicate 
what terminal, and what capabilities you have. So, what terminal name 
should putty report, and what would that mean on the host? Pretty much 
impossible to tell, since there are no standards.
Unless I remember wrong, you can set what string putty should report as 
the terminal name, and you should set it to whatever you want, which 
gives the correct result on your host.
"xterm" is a pretty well accepted standard string, which implies a bunch 
of (more or less) accepted capabilities. Color is *not* among them.

>> If someone else can show VMS doing more, and even better, under which
>> circumstances, I'm curious to look at how it is done. The contents of
>> DA1 does not provide enough information, with the possible exception
>> that if you get a CSI as the eight bit character, that is a pretty good
>> indication that maybe eightbit should be set. (That bit of information
>> is, by the way, what RSX use to set EBC, which is actually exactly how
>> much it really tells.)
>
> Unfortunately it does not, so creating an algorithm to do so is up to
> someone else.

Right.

> The only reliable way that I can see to get the current terminal
> geometry is to move the cursor to various locations and then read it
> back.  And with "linked" screens active, even that can return false
> information.  That is also something needed to detect broken wrap.

Yes.

> And there are a number of terminal properties that an application would
> be interested in that do not seem to be supported by the
> terminfo/termcap database or ncurses.

terminfo/termcap and (n)curses are broken in their own way.

> Set term/inquire has some unfortunate side effects, such as sometimes
> setting the terminal geometry back to 24 * 80, depending on what it finds.

That is because VMS tries to be clever. It's not inherent in DA1.

> The Curses library in VMS is broken.  It does not matter what terminal
> type you tell it to return values for, it always returns the values for
> a VT100.  So even changing the terminal settings will not affect a C
> program that uses it.

Fun. I've never looked at the curses library under VMS.

> In the GNV sourceforge CVS directory for the VMS (gnu_vms subtree)
> specific changes to BASH-4.2 is a replacement curses implementation that
> actually reads the VMS terminal database and has an alias for xterm, and
> possibly some other models.
>
> I did what I could, but many of the termcap/terminfo settings are not
> documented at all.
>
> Linux does not seem to even attempt to auto-detect a terminal type.

No Unix system do. The closest I've seen is tset, which tries to do 
something similar to what VMS does. But it only exist on some Unix 
systems, and it's definitely something you have to invoke on your own, 
and because of other inherent weirdness in Unix, it is not uncomplicated...

	Johnny

On 2012-08-01 12:53:09 +0000, John E. Malmberg said:

> On 8/1/2012 5:18 AM, Johnny Billquist wrote:
>> 
>> My point was that there is no response "seven bit". And believe me, I've
>> read the manuals backwards and forwards plenty of times.
>> I was curious on how people expected VMS to be able to set eightbit,
>> based on the information in DA1. Maybe something clever that I had
>> missed, but based on your responses, as well as the fact that VMS do not
>> set eightbit even if I have all the capabilities set correctly when I
>> test seems to prove that VMS does indeed not do this, as it can't.
> 
> VMS only seems to be able designed to detect a specific set of VT 
> series terminals that were sold by them or the company that now sells 
> them.  In some cases it can get the geometry of the terminal, in others 
> it can not.

And no support for changing the geometry live, either.
> 
>> If someone else can show VMS doing more, and even better, under which
>> circumstances, I'm curious to look at how it is done. The contents of
>> DA1 does not provide enough information, with the possible exception
>> that if you get a CSI as the eight bit character, that is a pretty good
>> indication that maybe eightbit should be set. (That bit of information
>> is, by the way, what RSX use to set EBC, which is actually exactly how
>> much it really tells.)
> 
> Unfortunately it does not, so creating an algorithm to do so is up to 
> someone else.

Or you do what has been done for ~30 years with VMS, and for longer 
with other platforms.  You read buggy manuals, screw around with the 
host settings, screw around with the wiring, screw around with the 
adapters, screw around with the intermediate networking hardware when 
necessary, chase down your occasional wiring glitch, and then screw 
around with the terminal settings.

Then tussle with the app-level oddities and errors.    Or GNU screen, 
and it's bugs.  Or tmux, where that's available.  Or chasing 
compatibility errors due to vendor compatibility with the bugs that 
were latent in the old (buggy) Hyperterm that was once integrated with 
Microsoft Windows.

Can't say I see the appeal of any of this.

Why do I keep hitting myself with the proverbial hammer: with mentions 
of serial comms and serial cables?  Because it feels so good when I 
stop...


> Serial communications is still used for many consoles and debugging or 
> diagnostic ports.  The terminal server market is apparently alive and 
> well.

Usually at the level of a minimal and possibly buggy VT100, maybe with 
buggy AVO.    This for those devices that are somewhere between a 
product with a JTAG port, and a product with an http/https web 
interface, or USB interface, or that are legacy products.  Microsoft 
was trying to nuke junk I/O back around the Windows XP era, after all, 
and the effort to slay the serial beast has only accellerated.

> One of the complaints about the current generation of low cost tablets 
> is that there is not a serial port that would allow technicians to use 
> them instead of carrying around a laptop.  In some cases an application 
> vendor is making a proprietary cable for serial communications.  But a 
> general solution is not available.

RedPark has available a serial adapter for iPad and iPhone.  ~US$60.  
Some app-related details 
<http://routing-bits.com/2012/07/05/get-console-review-on-the-ipad/> 
with RedPark.

Or connect via a Bluetooth serial adapter, where the widget supports 
Bluetooth Serial Port Profile (SSP) and where an app supports the 
widget.

> The D-Rats Amateur radio system uses serial communications, but can not 
> be used with either a Android tablet or iPad/iPod for that reason.
> 
> The future Microsoft Surface tablet supports a serial port through USB 
> and may be able to capture a bit of that market that has been written 
> off by others.  How big is it?  I do not know.

Haven't tried the USB serial dongle (TrippLite Keyspan USB to Serial 
adapter USA19HS) via an iPad via the camera kit, or (probably more 
likely to work) with the RedPark cable.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-08-01 13:22:55 +0000, Johnny Billquist said:

> On 2012-08-01 14:53, John E. Malmberg wrote:
>> On 8/1/2012 5:18 AM, Johnny Billquist wrote:
>>> 
>>> My point was that there is no response "seven bit". And believe me, I've
>>> read the manuals backwards and forwards plenty of times.
>>> I was curious on how people expected VMS to be able to set eightbit,
>>> based on the information in DA1. Maybe something clever that I had
>>> missed, but based on your responses, as well as the fact that VMS do not
>>> set eightbit even if I have all the capabilities set correctly when I
>>> test seems to prove that VMS does indeed not do this, as it can't.
>> 
>> VMS only seems to be able designed to detect a specific set of VT series
>> terminals that were sold by them or the company that now sells them.  In
>> some cases it can get the geometry of the terminal, in others it can not.
> 
> Well, yes and no. VMS does not detect specific terminals, but only uses 
> the somewhat generic responses from the DA1 escape sequence response. 
> Geometry is basically guessed (well, pretty much assumed) to be 24x80, 
> since almost all text terminals have that geometry.

Because it's a fracking mess.  Duh.

Keep picking at the scab, and you might eventually learn why most folks 
decided to hate on serial comms.

It was a reasonable compromise, err, choice, (many) years ago, but 
outside of a JTAG-type application, it's now a legacy connection.

And for good reason.

Someday, the kids will staring at those giant clunky serial adapters in 
some museum case, with no idea what a mess serial comms was.


-- 
Pure Personal Opinion | HoffmanLabs LLC

In article <jv98d1$kg2$1@dont-email.me>, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> writes:
> On 2012-07-31 19:20:41 +0000, Bob Koehler said:
> 
>>    That is 8 bit bytes on a serial line doesn't guarantee the hardware
>>    knows what to do with bytes above 255.
> 
> The eight-bit setting doesn't guarantee which characters the (usually 
> terminal) device will present to the end-user when an application 
> transmits bytes in the eight-bit 128 to 255 range, either.

   Ooops.  What I sould have said.  PDP-10 are the only systems I've
   worked woith having 9 bit and larger bytes.

In article <jv9f4h$t5m$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> 
> Trivia question: which function existed in the VT100 series, but was 
> removed in the VT200 series and newer, only to make a return in the 
> VT500 series? :-)

   I never had a 500, but I seem to recall VT52 mode, and the sequences
   to get to/from it, were not present after 100.

   Or is that just a parity slip in my grey matter?

On 2012-08-01 13:56:33 +0000, Bob Koehler said:

> In article <jv98d1$kg2$1@dont-email.me>, Stephen Hoffman 
> <seaohveh@hoffmanlabs.invalid> writes:
>> On 2012-07-31 19:20:41 +0000, Bob Koehler said:
>> 
>>> That is 8 bit bytes on a serial line doesn't guarantee the hardware
>>> knows what to do with bytes above 255.
>> 
>> The eight-bit setting doesn't guarantee which characters the (usually
>> terminal) device will present to the end-user when an application
>> transmits bytes in the eight-bit 128 to 255 range, either.
> 
>    Ooops.  What I sould have said.  PDP-10 are the only systems I've
>    worked woith having 9 bit and larger bytes.

Octets did eventually become the common unit of character encoding, but 
that took many years.

The UNIVAC 1100 series running EXEC-8 had 36-bit words, with 6-bit 
FIELDATA, and 9-bit ASCII character encodings.  DEC had a few of its 
own odd-ball character encodings, and some of the detritus of that era 
(eg: RAD50) still lurks in a few very dark corners of VMS.

As was mentioned earlier, there's simply no way to determine the 
character encoding of an arbitrary string.  Not without a tag or some 
other prearranged identifier, or specific knowledge of where the string 
came from.  You can assume, and you can guess, and you can guess 
incorrectly more often than your users might allow.  This also gets 
back to the MIME-format discussion, and the UTF-8 encoding discussions.

-- 
Pure Personal Opinion | HoffmanLabs LLC

On Wed, 01 Aug 2012 10:30:32 -0400, Stephen Hoffman wrote:

> Octets did eventually become the common unit of character encoding, but
> that took many years.
> 
> The UNIVAC 1100 series running EXEC-8 had 36-bit words, with 6-bit
> FIELDATA, and 9-bit ASCII character encodings.  DEC had a few of its own
> odd-ball character encodings, and some of the detritus of that era (eg:
> RAD50) still lurks in a few very dark corners of VMS.

The ICL 1900 series machines used 24 bit words, which could be used as 
four 6 bit characters.  IIRC parity came into the mix as well, though 
that might have been on the later 2900 series.

ISTR 48 character keyboards from that era.

-- 
Paul Sture

In article <jvbei8$5qe$1@dont-email.me>, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> writes:
> 
> As was mentioned earlier, there's simply no way to determine the 
> character encoding of an arbitrary string.

   Which is why I once thought of "encrypting" character data by a simple 
   cipher:  store it in EBCDIC.

Op woensdag 1 augustus 2012 15:49:12 UTC+2 schreef Stephen Hoffman het volg=
ende:

> It was a reasonable compromise, err, choice, (many) years ago, but
> outside of a JTAG-type application, it's now a legacy connection.
=20
For example:
I have a satellite receiver running Linux that sports a DB-9 serial interfa=
ce at the back for console purposes. The receiver is based on a system-in-a=
 chip Broadcom 7413 Mips processor. On the serial port only send, receive a=
nd ground are connected (I suspect using an on chip usb to serial adapter, =
but I'm no electronics engineer). Using the USB port to feed the GPS signal=
 including PPS over USB via a 5 euro USB to serial adapter (don't pay more,=
 it's really that cheap) produces a lot of jitter, apparently inherent to U=
SB. So now I use another little system with an old-fashioned serial port fo=
r that purpose.

>Someday, the kids will staring at those giant clunky serial adapters in
> some museum case, with no idea what a mess serial comms was.=20

From discussions here and elsewhere, USB is not the big step forward everyb=
ody hoped for, although soldering alternative cables can be eliminated as a=
 possible solution, that's at least some progress.

On Wed, 01 Aug 2012 13:34:42 -0500, Bob Koehler wrote:

> In article <jvbei8$5qe$1@dont-email.me>, Stephen Hoffman
> <seaohveh@hoffmanlabs.invalid> writes:
>> 
>> As was mentioned earlier, there's simply no way to determine the
>> character encoding of an arbitrary string.
> 
>    Which is why I once thought of "encrypting" character data by a
>    simple cipher:  store it in EBCDIC.

Chuckle.  Another thing COBOL can do easily.  ALPHABET IS EBCDIC was my 
friend there.

A seasoned IBMer could probably spot EBCDIC a mile off though.

-- 
Paul Sture

USB eliminated the terminal / modem (DTE-DCE IRRC) confusion about
pinouts and cross overs by formalising and limiting USB to a
master/slave architecrture with different plugs for each.

But that means you can't get a camera to talk to a phone because both
are defined as slaves.

Ethernet had that problem too, but now, many ethernet chips automaticaly
adapt and the need for crossover cables is less.

Being francophone with a � in my name, I always set serial equipment to
8 bits no parity. There were times when some equipment was configured to
7 bits with some parity and that caused me problems.

It was easy to test though. Typing an � on a non 8 bt line would cause
its high order bit to be chopped off and the character would come back
as an i.

If serial had evolved instead of being abandonned I suspect you'd see
most of its intricacies removed with more automated adapattion by the
serial chips.

On 2012-08-01 15:49, Stephen Hoffman wrote:
> On 2012-08-01 13:22:55 +0000, Johnny Billquist said:
>
>> On 2012-08-01 14:53, John E. Malmberg wrote:
>>> On 8/1/2012 5:18 AM, Johnny Billquist wrote:
>>>>
>>>> My point was that there is no response "seven bit". And believe me,
>>>> I've
>>>> read the manuals backwards and forwards plenty of times.
>>>> I was curious on how people expected VMS to be able to set eightbit,
>>>> based on the information in DA1. Maybe something clever that I had
>>>> missed, but based on your responses, as well as the fact that VMS do
>>>> not
>>>> set eightbit even if I have all the capabilities set correctly when I
>>>> test seems to prove that VMS does indeed not do this, as it can't.
>>>
>>> VMS only seems to be able designed to detect a specific set of VT series
>>> terminals that were sold by them or the company that now sells them.  In
>>> some cases it can get the geometry of the terminal, in others it can
>>> not.
>>
>> Well, yes and no. VMS does not detect specific terminals, but only
>> uses the somewhat generic responses from the DA1 escape sequence
>> response. Geometry is basically guessed (well, pretty much assumed) to
>> be 24x80, since almost all text terminals have that geometry.
>
> Because it's a fracking mess.  Duh.
>
> Keep picking at the scab, and you might eventually learn why most folks
> decided to hate on serial comms.
>
> It was a reasonable compromise, err, choice, (many) years ago, but
> outside of a JTAG-type application, it's now a legacy connection.
>
> And for good reason.
>
> Someday, the kids will staring at those giant clunky serial adapters in
> some museum case, with no idea what a mess serial comms was.

Nah. I have absolutely no problem with serial communication, or old 
fashioned terminals. But it all boils down to how much you knowledge you 
want to absorb. Lots of people mess with it, without understand it 
properly, and at that point I can understand all the confusion, errors 
and perceived mess.
But it's really not that problematic.

But I respect that not everyone cares to dig into it. Just like some 
people really do not want to do assembly language.

Me, I can't wrap my head around user interfaces. Whenever I try to do 
that stuff, it comes out horrible. Even I can see *that*. But I just 
can't seem to understand how to make something useful.

	Johnny

On 2012-08-01 15:58, Bob Koehler wrote:
> In article <jv9f4h$t5m$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>
>> Trivia question: which function existed in the VT100 series, but was
>> removed in the VT200 series and newer, only to make a return in the
>> VT500 series? :-)
>
>     I never had a 500, but I seem to recall VT52 mode, and the sequences
>     to get to/from it, were not present after 100.
>
>     Or is that just a parity slip in my grey matter?

A slip. Of course you can go to/from VT52 mode on all later VT terminals.

Hint: it is in an odd way related to the keyboard.

	Johnny

On 2012-08-01, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>
> But that means you can't get a camera to talk to a phone because both
> are defined as slaves.

Some devices implement USB On The Go, which allows devices to take
over as the master if there is no master present.

http://en.wikipedia.org/wiki/USB_OTG

Seems like an evil kludge to me, but there ya go...
-- 
roger ivie
rivie@ridgenet.net

On 1 aug, 17:01, Paul Sture <p...@sture.ch> wrote:
> On Wed, 01 Aug 2012 10:30:32 -0400, Stephen Hoffman wrote:
> > Octets did eventually become the common unit of character encoding, but
> > that took many years.
>
> > The UNIVAC 1100 series running EXEC-8 had 36-bit words, with 6-bit
> > FIELDATA, and 9-bit ASCII character encodings. =A0DEC had a few of its =
own
> > odd-ball character encodings, and some of the detritus of that era (eg:
> > RAD50) still lurks in a few very dark corners of VMS.
>
> The ICL 1900 series machines used 24 bit words, which could be used as
> four 6 bit characters. =A0IIRC parity came into the mix as well, though
> that might have been on the later 2900 series.
>
> ISTR 48 character keyboards from that era.
>
> --
> Paul Sture

IIRC The ICL 1900 used some form of EBCDIC. For sure it wasn't
compatible with the cards punched on a Burroughs B7700.

On 2012-08-02 03:06, Roger Ivie wrote:
> On 2012-08-01, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>
>> But that means you can't get a camera to talk to a phone because both
>> are defined as slaves.
>
> Some devices implement USB On The Go, which allows devices to take
> over as the master if there is no master present.
>
> http://en.wikipedia.org/wiki/USB_OTG
>
> Seems like an evil kludge to me, but there ya go...

I actually have a special cable for my phone, to do this. Exactly how 
special, if any, it is I don't know. But it plugs into the normal 
micro-USB port, and gives a normal USB port at the other end, where I 
can connect USB slaves.

	Johnny

On Thu, 02 Aug 2012 09:21:54 +0200, Johnny Billquist wrote:

> On 2012-08-02 03:06, Roger Ivie wrote:
>> On 2012-08-01, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>>
>>> But that means you can't get a camera to talk to a phone because both
>>> are defined as slaves.
>>
>> Some devices implement USB On The Go, which allows devices to take over
>> as the master if there is no master present.
>>
>> http://en.wikipedia.org/wiki/USB_OTG
>>
>> Seems like an evil kludge to me, but there ya go...
> 
> I actually have a special cable for my phone, to do this. Exactly how
> special, if any, it is I don't know. But it plugs into the normal
> micro-USB port, and gives a normal USB port at the other end, where I
> can connect USB slaves.

Was it a sensible price?  I remember buying ludicrously expensive serial 
cables for both Psion and Nokia.

-- 
Paul Sture

On Thu, 02 Aug 2012 01:10:48 +0200, Johnny Billquist wrote:

> But I respect that not everyone cares to dig into it. Just like some
> people really do not want to do assembly language.

I hated it many years ago when IBM told my employer that I didn't need 
assembler to do my job but in retrospect they were right.  It turned out 
that my time was better spent listening to end user or customer 
requirements and translating those requirements into terms that the bits 
and bytes folks could understand.
 
> Me, I can't wrap my head around user interfaces. Whenever I try to do
> that stuff, it comes out horrible. Even I can see *that*. But I just
> can't seem to understand how to make something useful.

You are not alone here.  If you go looking for themes for the CMS you are 
using you will quickly find that plenty that look good have horrible and 
unmaintainable code behind them and conversely plenty that have good 
maintainable code but look awful.

-- 
Paul Sture

On Wed, 01 Aug 2012 23:46:19 -0700, Hans Vlems wrote:

> On 1 aug, 17:01, Paul Sture <p...@sture.ch> wrote:
>> On Wed, 01 Aug 2012 10:30:32 -0400, Stephen Hoffman wrote:
>> > Octets did eventually become the common unit of character encoding,
>> > but that took many years.
>>
>> > The UNIVAC 1100 series running EXEC-8 had 36-bit words, with 6-bit
>> > FIELDATA, and 9-bit ASCII character encodings.  DEC had a few of its
>> > own odd-ball character encodings, and some of the detritus of that
>> > era (eg: RAD50) still lurks in a few very dark corners of VMS.
>>
>> The ICL 1900 series machines used 24 bit words, which could be used as
>> four 6 bit characters.  IIRC parity came into the mix as well, though
>> that might have been on the later 2900 series.
>>
>> ISTR 48 character keyboards from that era.
>>
> 
> IIRC The ICL 1900 used some form of EBCDIC. For sure it wasn't
> compatible with the cards punched on a Burroughs B7700.

According to the Wiki for the 1900 it used "a modification of an early 
version of ASCII, known by ICT as the ECMA character set, with some 
characters in different positions".

But the Wiki for the 2900 used ICL's own form of EBCDIC.

https://en.wikipedia.org/wiki/ICL_1900#Data_formats

https://en.wikipedia.org/wiki/ICL_2900_Series#Addressing_mechanisms

Interestingly the 2900 had the concept of Virtual Machines. Not to be 
confused with what we understand by that phrase today, these were more 
akin to processes or threads on other operating systems.


https://en.wikipedia.org/wiki/ICL_2900_Series#The_Virtual_Machine


-- 
Paul Sture

On 2012-08-01, Paul Sture <paul@sture.ch> wrote:
> On Wed, 01 Aug 2012 13:34:42 -0500, Bob Koehler wrote:
>
>> In article <jvbei8$5qe$1@dont-email.me>, Stephen Hoffman
>> <seaohveh@hoffmanlabs.invalid> writes:
>>> 
>>> As was mentioned earlier, there's simply no way to determine the
>>> character encoding of an arbitrary string.
>> 
>>    Which is why I once thought of "encrypting" character data by a
>>    simple cipher:  store it in EBCDIC.
>
> Chuckle.  Another thing COBOL can do easily.  ALPHABET IS EBCDIC was my 
> friend there.
>

Which EBCDIC variant would that be ? :-)

(Fortunately, EBCDIC is now a long distant memory for me. :-))

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2012-08-02 11:15, Paul Sture wrote:
> On Thu, 02 Aug 2012 09:21:54 +0200, Johnny Billquist wrote:
>
>> On 2012-08-02 03:06, Roger Ivie wrote:
>>> On 2012-08-01, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>>>
>>>> But that means you can't get a camera to talk to a phone because both
>>>> are defined as slaves.
>>>
>>> Some devices implement USB On The Go, which allows devices to take over
>>> as the master if there is no master present.
>>>
>>> http://en.wikipedia.org/wiki/USB_OTG
>>>
>>> Seems like an evil kludge to me, but there ya go...
>>
>> I actually have a special cable for my phone, to do this. Exactly how
>> special, if any, it is I don't know. But it plugs into the normal
>> micro-USB port, and gives a normal USB port at the other end, where I
>> can connect USB slaves.
>
> Was it a sensible price?  I remember buying ludicrously expensive serial
> cables for both Psion and Nokia.

It was included with the phone already. Nokia E7.

	JOhnny

On Thu, 02 Aug 2012 12:00:45 +0000, Simon Clubley wrote:

> On 2012-08-01, Paul Sture <paul@sture.ch> wrote:
>> On Wed, 01 Aug 2012 13:34:42 -0500, Bob Koehler wrote:
>>
>>> In article <jvbei8$5qe$1@dont-email.me>, Stephen Hoffman
>>> <seaohveh@hoffmanlabs.invalid> writes:
>>>> 
>>>> As was mentioned earlier, there's simply no way to determine the
>>>> character encoding of an arbitrary string.
>>> 
>>>    Which is why I once thought of "encrypting" character data by a
>>>    simple cipher:  store it in EBCDIC.
>>
>> Chuckle.  Another thing COBOL can do easily.  ALPHABET IS EBCDIC was my
>> friend there.
>>
>>
> Which EBCDIC variant would that be ? :-)
> 
> (Fortunately, EBCDIC is now a long distant memory for me. :-))
> 

I should have said VAX/DEC/Compaq/HP COBOL there.  It worked for all the 
IBM tapes I came across but IIRC if push came to shove you could define 
your own alphabet.  You mounted the tapes /FOREIGN and the labels were 
ANSI standard (as documented in the VMS I/O User Guide, so no need to 
reach for IBM documentation).  Retrieving the block and record lengths 
from those headers gave you the necessary information to unpack into RMS 
records.

-- 
Paul Sture

In article <bddoe9-amg1.ln1@news1.chingola.ch>, Paul Sture <paul@sture.ch> writes:
> 
> A seasoned IBMer could probably spot EBCDIC a mile off though.

   Which is why I decided against it.  At the time EBCDIC based systems
   from IBM were still fairly common.

   Does IBM even still use EBCDIC on thier "mainframes"?  I've got a green 
   card somewhere, but I haven't used any of thier systems is years.

   I still recall the first IBM system we got that worked in ASCII:  a
   desktop word processor that shipped a couple of years before the
   first PC.  But I'm not sure when IBM actually started using ASCII.

In article <cnaqe9-3b5.ln1@news1.chingola.ch>, Paul Sture <paul@sture.ch> writes:
>> 
> 
> I should have said VAX/DEC/Compaq/HP COBOL there.  It worked for all the 
> IBM tapes I came across but IIRC if push came to shove you could define 
> your own alphabet.  You mounted the tapes /FOREIGN and the labels were 
> ANSI standard (as documented in the VMS I/O User Guide, so no need to 
> reach for IBM documentation).  Retrieving the block and record lengths 
> from those headers gave you the necessary information to unpack into RMS 
> records.

   ANSI standard tape labels and IBM SL labels at one time differed in
   content only in ANSI labels being in ASCII and IBM SL being in EBCDIC.

   Or IBM could also write tapes in ASCII with ANSI labels, but
   disargeed with VMS on the maining of the EOV label.

   The IBM always ended tapes with EOV labels.  VMS took the presence of
   and EOV label to mean the data continued on another physical tape.

In article <jvcd7m$r3p$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> 
> Hint: it is in an odd way related to the keyboard.

   You mean the missing key?  Or using the SETUP key to manually switch
   modes?

On Thu, 02 Aug 2012 08:34:06 -0500, Bob Koehler wrote:

> In article <cnaqe9-3b5.ln1@news1.chingola.ch>, Paul Sture
> <paul@sture.ch> writes:
>>> 
>>> 
>> I should have said VAX/DEC/Compaq/HP COBOL there.  It worked for all
>> the IBM tapes I came across but IIRC if push came to shove you could
>> define your own alphabet.  You mounted the tapes /FOREIGN and the
>> labels were ANSI standard (as documented in the VMS I/O User Guide, so
>> no need to reach for IBM documentation).  Retrieving the block and
>> record lengths from those headers gave you the necessary information to
>> unpack into RMS records.
> 
>    ANSI standard tape labels and IBM SL labels at one time differed in
>    content only in ANSI labels being in ASCII and IBM SL being in
>    EBCDIC.
> 
>    Or IBM could also write tapes in ASCII with ANSI labels, but
>    disargeed with VMS on the maining of the EOV label.
> 
>    The IBM always ended tapes with EOV labels.  VMS took the presence of
>    and EOV label to mean the data continued on another physical tape.

As I wrote that post I realised I couldn't remember whether the labels 
themselves were in ASCII or EBCDIC.  I don't recall coming across 
multivolume tapes but what you say does ring a bell.

-- 
Paul Sture

On 2012-08-02 15:40, Bob Koehler wrote:
> In article <jvcd7m$r3p$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>
>> Hint: it is in an odd way related to the keyboard.
>
>     You mean the missing key?  Or using the SETUP key to manually switch
>     modes?

Nope. :-)
I might as well give the answer. It's the DECLL escape sequence, which 
is used to control some lights on the keyboard. The VT100 had four lamps 
marked L1 to L4 on the keyboard, the VT102 reused some of them for other 
purposes, but L1 remained. The feature was removed in the VT200, and 
reappeared in the VT500, where you can use the same escape sequence to 
control the lamps on the keyboard that normally indicate capslock, 
numlock and scroll lock.

	Johnny

On Thu, 02 Aug 2012 08:22:52 -0500, Bob Koehler wrote:

> In article <bddoe9-amg1.ln1@news1.chingola.ch>, Paul Sture
> <paul@sture.ch> writes:
>> 
>> A seasoned IBMer could probably spot EBCDIC a mile off though.
> 
>    Which is why I decided against it.  At the time EBCDIC based systems
>    from IBM were still fairly common.
> 
>    Does IBM even still use EBCDIC on thier "mainframes"?  I've got a
>    green card somewhere, but I haven't used any of thier systems is
>    years.
> 
>    I still recall the first IBM system we got that worked in ASCII:  a
>    desktop word processor that shipped a couple of years before the
>    first PC.  But I'm not sure when IBM actually started using ASCII.

According to

https://en.wikipedia.org/wiki/EBCDIC#History

IBM were on the ASCII committee but adopted EBCDIC but didn't have time 
to convert their peripherals before shipping so stayed with EBCDIC.

"... but AIX running on the iSeries, Linux running on the zSeries, and 
the IBM PC and its descendants use ASCII."

"The collating sequence of lower case alphabetic characters is higher 
than upper case and numerics are higher still — the exact opposite of 
ASCII."

The collating sequence got me at one stage.  I was wondering if we had 
enough disk space to sort a very large input file into ASCII sequence, 
then it occurred to me to do two passes up the file outputting the 
numerics first.

-- 
Paul Sture

Paul Sture <paul@sture.ch> wrote:

(snip)
>>    I still recall the first IBM system we got that worked in ASCII:  a
>>    desktop word processor that shipped a couple of years before the
>>    first PC.  But I'm not sure when IBM actually started using ASCII.

> According to

> https://en.wikipedia.org/wiki/EBCDIC#History

> IBM were on the ASCII committee but adopted EBCDIC but didn't have time 
> to convert their peripherals before shipping so stayed with EBCDIC.

When designing S/360, it seems that there was a proposed ASCII-8
(eight bit ASCII) that never appeared. (Not just ASCII-7 with an
extra bit added.) IBM never used it, and the PSW bit was reused
to allow virtual addressing in S/370.

> "... but AIX running on the iSeries, Linux running on the zSeries, and 
> the IBM PC and its descendants use ASCII."

Must be some interesting conversion somewhere along the way for
Linux/390, but yes.

(snip)

-- glen

On Thu, 02 Aug 2012 16:29:25 +0000, glen herrmannsfeldt wrote:

> Paul Sture <paul@sture.ch> wrote:
> 
> 
>> https://en.wikipedia.org/wiki/EBCDIC#History
> 
> 
>> "... but AIX running on the iSeries, Linux running on the zSeries, and
>> the IBM PC and its descendants use ASCII."
> 
> Must be some interesting conversion somewhere along the way for
> Linux/390, but yes.

According to that Wiki article:

"Software and many hardware peripherals can translate to and from 
encodings, and modern mainframes (such as IBM zSeries) include processor 
instructions, at the hardware level, to accelerate translation between 
character sets."

-- 
Paul Sture

In article <jve1ul$brn$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:

> I might as well give the answer. It's the DECLL escape sequence, which 
> is used to control some lights on the keyboard.

   I have a test program which runs throught the LEDs on VT100.  I've
   run it on VT200, 300, and 400, a couple of hardware VT clones, and
   several software VT emulators.

   I don't recall a light on VT200 responding, but all those which were
   not VT100 accepted and ignored the sequences without error.

   So I just figured the lights were "virtual".

In article <seqe9-3b5.ln1@news1.chingola.ch>, Paul Sture <paul@sture.ch> writes:
> 
> "The collating sequence of lower case alphabetic characters is higher 
> than upper case and numerics are higher still — the exact opposite of 
> ASCII."
> 
> The collating sequence got me at one stage.  I was wondering if we had 
> enough disk space to sort a very large input file into ASCII sequence, 
> then it occurred to me to do two passes up the file outputting the 
> numerics first.

   Since A .lt. B depends on the charaacter set, Fortran added functions 
   to compare characters according to the ASCII collating sequence quite 
   a while ago.

   All the ASCII based systems I had access to since then support the
   new functions.  I haven't had to look at IBM's Fortran in decades,
   but the last time I did that part of the Fortran standard was 
   documented by IBM as unsupported on thier EBCDIC based mainframes.
   
   So the one place you really needed them, you got to roll your own.

In article <jve9t5$5ir$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> Must be some interesting conversion somewhere along the way for
> Linux/390, but yes.

   While OS and utilities may be written to one character set or
   another, I've never seen an instruction set that favored one.

   Printers and terminals are the only peripherals I can think of
   that would differ.

   Even card readers/punches I've dealt with could read/punch either
   026 (BCD) or 029 (EBCDIC), via translation in the interface software.

On 2012-08-02 17:46:00 +0000, Bob Koehler said:

> In article <seqe9-3b5.ln1@news1.chingola.ch>, Paul Sture 
> <paul@sture.ch> writes:
>> 
>> "The collating sequence of lower case alphabetic characters is higher
>> than upper case and numerics are higher still — the exact opposite of
>> ASCII."
>> 
>> The collating sequence got me at one stage.  I was wondering if we had
>> enough disk space to sort a very large input file into ASCII sequence,
>> then it occurred to me to do two passes up the file outputting the
>> numerics first.
> 
>    Since A .lt. B depends on the charaacter set, Fortran added functions
>    to compare characters according to the ASCII collating sequence quite
>    a while ago.

Collation depends on the character encoding, and on the language.

(And the collation sequences aren't as static as might be expected.  
Spanish changed its collation for ch and ll a few years back, for 
instance.)

The National Replacement Character Set (NCS, et al) dealt with this on 
OpenVMS, but AFAIK that tool and that API has been deprecated.  Which 
leaves programmers with the I18N, locale and iconv-related pieces and 
the C library.  Or porting, or rolling your own.

-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-08-02 19:41, Bob Koehler wrote:
> In article <jve1ul$brn$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>
>> I might as well give the answer. It's the DECLL escape sequence, which
>> is used to control some lights on the keyboard.
>
>     I have a test program which runs throught the LEDs on VT100.  I've
>     run it on VT200, 300, and 400, a couple of hardware VT clones, and
>     several software VT emulators.
>
>     I don't recall a light on VT200 responding, but all those which were
>     not VT100 accepted and ignored the sequences without error.

You don't get "errors" for unknown escape sequences. Escape sequences 
can't give errors. If it's unknown/undefined, it's just a case of 
"nothing happens".

>     So I just figured the lights were "virtual".

:-)

Anyway, the VT500 (at least 520/525) do have lights that can be 
controlled. Same as the VT100.

	Johnny

On 2012-08-02 18:41, Paul Sture wrote:
> On Thu, 02 Aug 2012 16:29:25 +0000, glen herrmannsfeldt wrote:
>
>> Paul Sture <paul@sture.ch> wrote:
>>
>>
>>> https://en.wikipedia.org/wiki/EBCDIC#History
>>
>>
>>> "... but AIX running on the iSeries, Linux running on the zSeries, and
>>> the IBM PC and its descendants use ASCII."
>>
>> Must be some interesting conversion somewhere along the way for
>> Linux/390, but yes.
>
> According to that Wiki article:
>
> "Software and many hardware peripherals can translate to and from
> encodings, and modern mainframes (such as IBM zSeries) include processor
> instructions, at the hardware level, to accelerate translation between
> character sets."

You mean something like MOVTC from a well known architecture that plays 
an important role in the history of VMS? :-)

	Johnny

Paul Sture <paul@sture.ch> wrote:

(snip regarding IBM, EBCDIC, and ASCII, then I wrote)

>> Must be some interesting conversion somewhere along the way for
>> Linux/390, but yes.

> According to that Wiki article:

> "Software and many hardware peripherals can translate to and from 
> encodings, and modern mainframes (such as IBM zSeries) include processor 
> instructions, at the hardware level, to accelerate translation between 
> character sets."

Well, TR goes back to S/360. 

Printers would usually expect EBCDIC. Consoles terminals often
(tracing back to S/360 days) often have a different code.

If you run as a VM guest, then VM would normally support
EBCDIC for spooled I/O. Disks, of course, are written however
the program writes them. 

Does remind me of trying to get a S/370 disassembler, written
in C, to run under unix/ASCII. All the symbols from the object
program come out in EBCDIC and need to be converted.

-- glen

Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:

(snip regarding EBCDIC and ASCII)

>   While OS and utilities may be written to one character set or
>   another, I've never seen an instruction set that favored one.

For S/360 and descendants, UNPACK and the decimal instructions.

Closer to VMS, look at the VAX CVTPT and CTRRP instructions.
Also, the prefered signs for packed decimal instructions.

>   Printers and terminals are the only peripherals I can think of
>   that would differ.

and card readers (real or virtual). If you connect a terminal
to a 3705 through VM, though, an ASCII terminal would convert
to EBCDIC, then back to ASCII again!

>   Even card readers/punches I've dealt with could read/punch either
>   026 (BCD) or 029 (EBCDIC), via translation in the interface software.

Well, the letters, numbers, and many special characters are
the same. Even so, a byte for byte translation is likely done.

-- glen

On 8/1/2012 8:49 AM, Stephen Hoffman wrote:
> On 2012-08-01 13:22:55 +0000, Johnny Billquist said:
>
> Keep picking at the scab, and you might eventually learn why most folks
> decided to hate on serial comms.
>
> It was a reasonable compromise, err, choice, (many) years ago, but
> outside of a JTAG-type application, it's now a legacy connection.
>
> And for good reason.
>
> Someday, the kids will staring at those giant clunky serial adapters in
> some museum case, with no idea what a mess serial comms was.

Which I still need to use on production machines on a regular basis 
because sometimes that newfangled GUI interface stops functioning, and 
an SSH or Telnet connection is the only thing left to reach the machine 
on the other side of the country and fix it.

I also need it for daily for functional test automation as the tools 
that use the GUI are typically extremely slow in running, and break with 
the slightest change in the application, or platform that the 
application runs on, yet the CLI continues to be backwards compatible.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only

On Thu, 02 Aug 2012 12:46:00 -0500, Bob Koehler wrote:

> In article <seqe9-3b5.ln1@news1.chingola.ch>, Paul Sture <paul@sture.ch>
> writes:
>> 
>> "The collating sequence of lower case alphabetic characters is higher
>> than upper case and numerics are higher still — the exact opposite of
>> ASCII."
>> 
>> The collating sequence got me at one stage.  I was wondering if we had
>> enough disk space to sort a very large input file into ASCII sequence,
>> then it occurred to me to do two passes up the file outputting the
>> numerics first.
> 
>    Since A .lt. B depends on the charaacter set, Fortran added functions
>    to compare characters according to the ASCII collating sequence quite
>    a while ago.
> 
>    All the ASCII based systems I had access to since then support the
>    new functions.  I haven't had to look at IBM's Fortran in decades,
>    but the last time I did that part of the Fortran standard was
>    documented by IBM as unsupported on thier EBCDIC based mainframes.
>    
>    So the one place you really needed them, you got to roll your own.

Great eh?

Did you realise that the default collating sequence for MySQL is 
latin1_swedish_ci?

http://www.sitebuddy.com/mssql_info/
mysql_character_sets_and_collation_explained

"The default server level can be change in your my.ini configuration file 
with the directive default-character-set (--default-character-
set=character_set_name and ). If not specific the default is latin1. And 
the default collation for latin1 is latin1_swedish_ci"

And um, I wanted to quote from the official MySQL documentation there but 
Oracle have merged its search function into the rest of their products 
and I ended up with a load of PL/SQL hits.

-- 
Paul Sture

Paul Sture wrote 2012-08-03 12:12:
> On Thu, 02 Aug 2012 12:46:00 -0500, Bob Koehler wrote:
>
>> In article <seqe9-3b5.ln1@news1.chingola.ch>, Paul Sture <paul@sture.ch>
>> writes:
>>>
>>> "The collating sequence of lower case alphabetic characters is higher
>>> than upper case and numerics are higher still — the exact opposite of
>>> ASCII."
>>>
>>> The collating sequence got me at one stage.  I was wondering if we had
>>> enough disk space to sort a very large input file into ASCII sequence,
>>> then it occurred to me to do two passes up the file outputting the
>>> numerics first.
>>
>>     Since A .lt. B depends on the charaacter set, Fortran added functions
>>     to compare characters according to the ASCII collating sequence quite
>>     a while ago.
>>
>>     All the ASCII based systems I had access to since then support the
>>     new functions.  I haven't had to look at IBM's Fortran in decades,
>>     but the last time I did that part of the Fortran standard was
>>     documented by IBM as unsupported on thier EBCDIC based mainframes.
>>
>>     So the one place you really needed them, you got to roll your own.
>
> Great eh?
>
> Did you realise that the default collating sequence for MySQL is
> latin1_swedish_ci?
>
> http://www.sitebuddy.com/mssql_info/
> mysql_character_sets_and_collation_explained
>
> "The default server level can be change in your my.ini configuration file
> with the directive default-character-set (--default-character-
> set=character_set_name and ). If not specific the default is latin1. And
> the default collation for latin1 is latin1_swedish_ci"
>
> And um, I wanted to quote from the official MySQL documentation there but
> Oracle have merged its search function into the rest of their products
> and I ended up with a load of PL/SQL hits.
>

How is the "granulatity" of collating sequences in MySQL ?

In Rdb, you can set specific collating seqences on table and field level.
I once used this to get an automatic "sort" on a serial code field that
used A-Z and 0-9 "in reverse" as the numbering. In this case there was
no builtin collating sequence but that was easily added using the standard
OpenVMS (not Rdb specific) tools and then referenced from the Rdb
CREATE TABLE command.

Jan-Erik.

In article <jvelpr$3ka$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> Does remind me of trying to get a S/370 disassembler, written
> in C, to run under unix/ASCII. All the symbols from the object
> program come out in EBCDIC and need to be converted.

   Written in C?  I thought EBCDIC didn't have {}, isn't that why
   RATFOR allowed <> as substitutes?

In article <gokse9-ip7.ln1@news1.chingola.ch>, Paul Sture <paul@sture.ch> writes:
> 
> Did you realise that the default collating sequence for MySQL is 
> latin1_swedish_ci?

   Nope.  If it has anything to do with a DBMS, I stay clear of it
   as much as I can.

Bob Koehler wrote 2012-08-03 15:18:
> In article <jvelpr$3ka$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>
>> Does remind me of trying to get a S/370 disassembler, written
>> in C, to run under unix/ASCII. All the symbols from the object
>> program come out in EBCDIC and need to be converted.
>
>     Written in C?  I thought EBCDIC didn't have {},

http://en.wikipedia.org/wiki/EBCDIC_37

In article <dTd5Kk0lwIU2@eisner.encompasserve.org>,
koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <jvelpr$3ka$1@speranza.aioe.org>, glen herrmannsfeldt
> <gah@ugcs.caltech.edu> writes:
> > 
> > Does remind me of trying to get a S/370 disassembler, written
> > in C, to run under unix/ASCII. All the symbols from the object
> > program come out in EBCDIC and need to be converted.
> 
>    Written in C?  I thought EBCDIC didn't have {}, isn't that why
>    RATFOR allowed <> as substitutes?

I don't remember this is as being a real showstopper.
TeX would have had the same problem, yet a lot of colleagues
used it to prepare their theses on mainframes.
I only remember difficulties to enter [] on 3270 terminal keyboards,
one had to use the ISPF editor's hex mode to enter some hex byte
which would be recognized as square brackets. But you don't need [] much.

C/370 also allowed trigraphs to model those strange bracket types, iirc.

Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:
> In article <jvelpr$3ka$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> 
>> Does remind me of trying to get a S/370 disassembler, written
>> in C, to run under unix/ASCII. All the symbols from the object
>> program come out in EBCDIC and need to be converted.

>   Written in C?  I thought EBCDIC didn't have {}, isn't that why
>   RATFOR allowed <> as substitutes?

I believe the TN print train has them, though I don't remember
using them. (The more common print trains don't.)

In any case, there have been EBCDIC versions of C for some time now.
(C has substitutes for some characters, too.)

Also, reminds me of comments in the PL/I (F) library related to
the character set used. Many routines are specifically character
set independent. Others have comments indicating that if converted
to a different character set (or, at least, character constants
are converted) then they will work in that character set.

The Tachyon assemblers allow source input in either ASCII
or EBCDIC, but assemble constants in EBCDIC in either case.
(Maybe there is an option to assemble constants in ASCII.)

--glen

In article <jvgoc4$q3r$1@speranza.aioe.org>,
	glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:
>> In article <jvelpr$3ka$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>> 
>>> Does remind me of trying to get a S/370 disassembler, written
>>> in C, to run under unix/ASCII. All the symbols from the object
>>> program come out in EBCDIC and need to be converted.
> 
>>   Written in C?  I thought EBCDIC didn't have {}, isn't that why
>>   RATFOR allowed <> as substitutes?
> 
> I believe the TN print train has them, though I don't remember
> using them. (The more common print trains don't.)
> 
> In any case, there have been EBCDIC versions of C for some time now.
> (C has substitutes for some characters, too.)
> 
> Also, reminds me of comments in the PL/I (F) library related to
> the character set used. Many routines are specifically character
> set independent. Others have comments indicating that if converted
> to a different character set (or, at least, character constants
> are converted) then they will work in that character set.
> 
> The Tachyon assemblers allow source input in either ASCII
> or EBCDIC, but assemble constants in EBCDIC in either case.
> (Maybe there is an option to assemble constants in ASCII.)
> 

While I never did C on an IBM mainframe I do remember getting C
programs thru BITNET and having to run them thru a program I wrote
to ASCIIfy them before I could use them on other systems.

Hmmm...  Wonder if that program is still sitting somewhere in my
files at the University?

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>