On 2013-03-05 21:56, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
On 2013-03-05 21:33, Johnny Billquist wrote:
On 2013-03-05 21:18, Brian Schenkenberger, VAXman- wrote:
Clem Cole <clemc at ccc.com> writes:
Yep. From the FAQ:
The emulation level for xterm is set via the resource decTerminalID,
*e.g.*,
to 220 for a VT220. Once set, applications can set the emulation
level up
or down within that limit. DEC's terminals are configured in much the
same
way by a setup option.
Yup... .Xresources has "decTerminalID: vt200" but that still doesn't
excuse
it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL
when it's
set for vt200.
Note that the value should be set to "220", not "vt220", nor "vt200".
And I should correct myself. Leading letters are ignored in
decTerminalID, so vt220 works just as well as 220. However, vt200 will
probably still not create the desired result.
And you need the resource class or resource name in there as well, so
just a plain decTerminalID in your x resources will not work right.
I'll have to stop postin shorthand for you...
:-)
XTerm.vt100.decTerminalID: vt200
Now change that to "vt220". :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Interesting - really love to see the sources. I wonder what is different / has changed. By the early 2000s (pre compaq-tion) many/most of the systems developers on my team in MRO and ZKO, used xterms to get the vms systems for development (i.e we tended to use Alpha workstations but still needed to support some systems functions that ran on VMS). I supposed some must have used a PC for some of that work, but many of us just used our DS100's or the like running Tru64.
Hmm = you tests are interesting data - maybe more of them used DECterms than I thought and we never noticed.
Clem
On Tue, Mar 5, 2013 at 4:19 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
Clem Cole <clemc at ccc.com> writes:
>try xterm.vt100.decTerminalID: 220
>Which was my memory, I'd check to the sources for sure.
>
>Also, don't forget to restart X. The .Xresource stuff was always hokey
>and if things are not perfect, bad things happen. I've spent way more time
>than I want to think dealing with Xresource crap over the years (and
>b*tching at authors).
>
>Clem
Doesn't make a bit of difference. Still doesn't give me DECDWL or DECDHL,
and the debugger issue still persists.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Clem Cole <clemc at ccc.com> writes:
try xterm.vt100.decTerminalID: 220
Which was my memory, I'd check to the sources for sure.
Also, don't forget to restart X. The .Xresource stuff was always hokey
and if things are not perfect, bad things happen. I've spent way more time
than I want to think dealing with Xresource crap over the years (and
b*tching at authors).
Clem
Doesn't make a bit of difference. Still doesn't give me DECDWL or DECDHL,
and the debugger issue still persists.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
try xterm.vt100.decTerminalID: 220
Which was my memory, I'd check to the sources for sure.
Also, don't forget to restart X. The .Xresource stuff was always hokey and if things are not perfect, bad things happen. I've spent way more time than I want to think dealing with Xresource crap over the years (and b*tching at authors).
Clem
On Tue, Mar 5, 2013 at 3:56 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
Johnny Billquist <bqt at softjar.se> writes:
>On 2013-03-05 21:33, Johnny Billquist wrote:
>> On 2013-03-05 21:18, Brian Schenkenberger, VAXman- wrote:
>>> Clem Cole <clemc at ccc.com> writes:
>>>
>>>> Yep. From the FAQ:
>>>>
>>>> The emulation level for xterm is set via the resource decTerminalID,
>>>> *e.g.*,
>>>> to 220 for a VT220. Once set, applications can set the emulation
>>>> level up
>>>> or down within that limit. DEC's terminals are configured in much the
>>>> same
>>>> way by a setup option.
>>>
>>> Yup... .Xresources has "decTerminalID: vt200" but that still doesn't
>>> excuse
>>> it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL
>>> when it's
>>> set for vt200.
>>
>> Note that the value should be set to "220", not "vt220", nor "vt200".
>
>
>And I should correct myself. Leading letters are ignored in
>decTerminalID, so vt220 works just as well as 220. However, vt200 will
>probably still not create the desired result.
>
>And you need the resource class or resource name in there as well, so
>just a plain decTerminalID in your x resources will not work right.
I'll have to stop postin shorthand for you...
XTerm.vt100.decTerminalID: vt200
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Johnny Billquist <bqt at softjar.se> writes:
On 2013-03-05 21:33, Johnny Billquist wrote:
On 2013-03-05 21:18, Brian Schenkenberger, VAXman- wrote:
Clem Cole <clemc at ccc.com> writes:
Yep. From the FAQ:
The emulation level for xterm is set via the resource decTerminalID,
*e.g.*,
to 220 for a VT220. Once set, applications can set the emulation
level up
or down within that limit. DEC's terminals are configured in much the
same
way by a setup option.
Yup... .Xresources has "decTerminalID: vt200" but that still doesn't
excuse
it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL
when it's
set for vt200.
Note that the value should be set to "220", not "vt220", nor "vt200".
And I should correct myself. Leading letters are ignored in
decTerminalID, so vt220 works just as well as 220. However, vt200 will
probably still not create the desired result.
And you need the resource class or resource name in there as well, so
just a plain decTerminalID in your x resources will not work right.
I'll have to stop postin shorthand for you...
XTerm.vt100.decTerminalID: vt200
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
It's pretty much done except for the IPSec stuff, but that's just getting the right config options loaded in and is trivial.
It's here if anyone is interested in seeing how it works.
http://bart.4amlunch.net/misc/tunnels/
-brian
On 2013-03-05 21:33, Johnny Billquist wrote:
On 2013-03-05 21:18, Brian Schenkenberger, VAXman- wrote:
Clem Cole <clemc at ccc.com> writes:
Yep. From the FAQ:
The emulation level for xterm is set via the resource decTerminalID,
*e.g.*,
to 220 for a VT220. Once set, applications can set the emulation
level up
or down within that limit. DEC's terminals are configured in much the
same
way by a setup option.
Yup... .Xresources has "decTerminalID: vt200" but that still doesn't
excuse
it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL
when it's
set for vt200.
Note that the value should be set to "220", not "vt220", nor "vt200".
And I should correct myself. Leading letters are ignored in decTerminalID, so vt220 works just as well as 220. However, vt200 will probably still not create the desired result.
And you need the resource class or resource name in there as well, so just a plain decTerminalID in your x resources will not work right.
Johnny
On 2013-03-05 21:18, Brian Schenkenberger, VAXman- wrote:
Clem Cole <clemc at ccc.com> writes:
Yep. From the FAQ:
The emulation level for xterm is set via the resource decTerminalID, *e.g.*,
to 220 for a VT220. Once set, applications can set the emulation level up
or down within that limit. DEC's terminals are configured in much the same
way by a setup option.
Yup... .Xresources has "decTerminalID: vt200" but that still doesn't excuse
it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL when it's
set for vt200.
Note that the value should be set to "220", not "vt220", nor "vt200".
Actually, for me:
xrdb -query | grep decTerminalID
gives
*.vt100.decTerminalID: 220
Check that you have things actually set correctly... If you just have decTerminalID, it will not even be associated with xterm. (Xresources are often a somewhat obscure thing.)
DECDWL and DECDHL works just fine for me. That could be a font issue in your environment.
Johnny
Clem Cole <clemc at ccc.com> writes:
Yep. From the FAQ:
The emulation level for xterm is set via the resource decTerminalID, *e.g.*,
to 220 for a VT220. Once set, applications can set the emulation level up
or down within that limit. DEC's terminals are configured in much the same
way by a setup option.
Yup... .Xresources has "decTerminalID: vt200" but that still doesn't excuse
it for misbehaving as one. ;) It also doesn't do DECDWL or DECDHL when it's
set for vt200.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On 5.3.2013 13:17, Brian Schenkenberger, VAXman- wrote:
=?ISO-8859-1?Q?Kari_Uusim=E4ki?= <uusimaki at exdecfinland.org> writes:
It is called PowerTerm and it was included in the last Pathworks 32 kits.
It is produced by Ericom. An Israeli company, indeed.
Ericom is Headquartered here in Closter, New Jersey.
I won't argue, but I assume you mean the US Headquarters.
If you look at the Ericom's management page, there's definitive evidence about the Israeli origin.
You can still buy it from Ericom's resellers. Nowadays, it is called
PowerTerm Interconnect.
Btw. It is a lot cheaper than e.g. Reflection.
But their support and responsiveness to problems is poor. I tried to
get the PowerTerm for Linux to pass some of the more basic VTTEST and
their support never bothered to even respond other than the automated
"we've received your support request" emails.
I'm surprised!
Last year we were working on a MPE (HP3000) project and found a bug in PowerTerm (HP 700 emulation). When I reported it to the Ericom support, I got an answer the next day and the issue was fixed in a week.
I've been using PowerTerm since it became a part of the Pathworks 32 kit and never had issues. Maybe I am not a real power user since I use it for regular system management, as a console terminal for VAXen, Alphas and many other RISC machines plus console connections to (DEC and other brands) network equipment.
I cannot tell anything about the Linux version, because I've not tested it. Just the windows version.
