On 6 Mar 2013, at 02:04, Gregg Levine <gregg.drwho8 at gmail.com> wrote:
It gets screwier. The New York State College of Optometry again in
Manhattan is still using an entire DEC based solution for their work.
I certainly hope they hired the right hobbyist to maintain their
gear.......
I think my alma mater (Royal Holloway, Uni. of London) still uses a couple of AlphaServers for their student registration at the beginning of each year and some more VMS boxes for print servers for the on-campus labs.
I actually managed to borrow some VMS install media from the admin guys, they were more than happy to help a hobbyist out :)
sampsa
On Tue, Mar 5, 2013 at 6:51 PM, Johnny Billquist <bqt at softjar.se> wrote:
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
Hello!
Here's an interesting tidbit. The first time I saw a cluster of these
terminals was about fifteen years previously. They were used to manage
the entire line of business of the Federation Employment Guidance
Service over in Manhattan. Then about the time they switched over to
something other then the VAX (and this despite the fact that their
kludgy billing and record keeping solution runs only on that
platform.) I believed then that they first went for the Alpha and
someone else worked out how to have this <Expletive Deleted!> working
there. And then they were using the PC to talk to their solution and
still using DECNet.
Then when I started in earnest visiting the Queens Borough Public
Library they were entirely DEC based complete with (you guessed it!)
these terminals to do everything.
Now they too are gone.
It gets screwier. The New York State College of Optometry again in
Manhattan is still using an entire DEC based solution for their work.
I certainly hope they hired the right hobbyist to maintain their
gear.......
Oh and Dave please stop staring at the visiting Timelord. He's there
to buy the entire island where an idiot placed an atomic energy
plant.... And please stop trying to pay the Yetis who are throw
snowballs at you.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 2013-03-05 22:19, Brian Schenkenberger, VAXman- 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.
So, DECDWL and DECHDL are noted in the xterm documentation that it depends on your fonts. So unless you have an old version, or bad fonts, it should work. Does it work if you have it set to vt100?
Not sure what the debugger issues were.
Anyway, we might be beating on a dead horse here. It might that you're actually not that interested in getting this working, if you have another solution that do work for you.
All I can say is that at my place, xterm do handle DECDWL and DECDHL just fine.
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
On 2013-03-05 22:05, Clem Cole wrote:
try xterm.vt100.decTerminalID: 220
Which was my memory, I'd check to the sources for sure.
No, that is right. It should be 220, and not 200.
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).
Uh. Xresources are really not that hard. You can always query the current values. No need to ever restart because of it. But you do need to make sure you have loaded the values. But with xrdb you can either merge new values in, or remove all the old values. I'd say you have pretty good control over this aspect.
Figuring out the names of the keys in the xresources is another story, however.
Johnny
Clem
On Tue, Mar 5, 2013 at 3:56 PM, Brian Schenkenberger, VAXman-
<system at tmesis.com <mailto:system at tmesis.com>> wrote:
Johnny Billquist <bqt at softjar.se <mailto: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 <mailto: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 || "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
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
