kms@ecsvax.uncecs.edu (Ken Steele) (06/06/91)
Does Handshake support extended length packets in file transfers
with Kermit? Even though I execute a 'set send packet-length
900' (or some such value) on the mainframe, I still receive the
file in spits of 90 bytes.
If you don't know the answer to the first question, then how
about this one. Handshake is set for VT102 mode. When I
am logged into one Vax and then telnet to another Vax, upon
connecting, Handshake flips into VT220 mode, the cursor dives
to the bottom right of the screen and stays there until I
manually change the term setting back to VT102. Is there a
way to prevent this? Or am I doomed to an eternity of doubt
about what was in the login message :-)
--
Ken Steele Dept. of Psychology kms@ecsvax.bitnet
Mars Hill College kms@ecsvax.uncecs.edu
Mars Hill, NC 28754 {some big name site}!mcnc!ecsvax!kms ake@dayton.saic.com (Earle Ake) (06/06/91)
In article <1991Jun6.030522.3061@ecsvax.uncecs.edu>, kms@ecsvax.uncecs.edu (Ken Steele) writes: > If you don't know the answer to the first question, then how > about this one. Handshake is set for VT102 mode. When I > am logged into one Vax and then telnet to another Vax, upon > connecting, Handshake flips into VT220 mode, the cursor dives > to the bottom right of the screen and stays there until I > manually change the term setting back to VT102. Is there a > way to prevent this? Or am I doomed to an eternity of doubt > about what was in the login message :-) If you use the command 'set terminal/inquire' on the VAX, the VAX sends out an escape sequence and the terminal reports back what type it is with an escape sequence. The problem is Handshake also sets itself to VT220 mode 'for you'. It shouldn't do this and it is a bug. Send a message to Eric and have him look at it. I sent a message to him about it a year ago. I didn't get a response and it hasn't been fixed. I am now using JR-Comm. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake
thad@public.BTR.COM (Thaddeus P. Floryan) (06/07/91)
In article <1991Jun6.030522.3061@ecsvax.uncecs.edu> kms@ecsvax.uncecs.edu (Ken Steele) writes: >[...] >Handshake is set for VT102 mode. When I >am logged into one Vax and then telnet to another Vax, upon >connecting, Handshake flips into VT220 mode, the cursor dives >to the bottom right of the screen and stays there until I >manually change the term setting back to VT102. Is there a >way to prevent this? Or am I doomed to an eternity of doubt >about what was in the login message :-) >[...] You say "Vax" but I suspect you mean a Vax running VMS. What's doing-you-in is a "SET TERM/INQUIRE". Check your LOGIN.COM for that (^^^^^^^^^^) and remove it. If you're unfortunate enough to have a system where the SET TERM/INQUIRE is in the system-wide LOGIN.COM, then either ask your site admin to remove that from that file OR to alter your UAF entry to NOT execute the system-wide LOGIN.COM and to just execute your personal LOGIN.COM instead. Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
c506634@umcvmb.missouri.edu (Eric Edwards) (06/07/91)
> Does Handshake support extended length packets in file transfers > with Kermit? Even though I execute a 'set send packet-length The kermit protocal built into Handshake 2.20c does not support long packtes. However, Handshake does support external protocal libraries. XPRKermit DOES support long packets. Eric Edwards: c506634 @ "I say we take off and nuke the entire site Inet: umcvmb.missouri.edu from orbit. It's the only way to be sure." Bitnet: umcvmb.bitnet -- Sigourney Weaver, _Aliens_
consp03@bingsuns.cc.binghamton.edu (Kriston J. Rehberg) (06/09/91)
In article <1991Jun6.101336.1659@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: |> If you use the command 'set terminal/inquire' on the VAX, the VAX sends |>out an escape sequence and the terminal reports back what type it is with an |>escape sequence. The problem is Handshake also sets itself to VT220 mode |>'for you'. It shouldn't do this and it is a bug. Send a message to Eric and ^^^^^^^^^^^ nope, it's not a bug! |>have him look at it. I sent a message to him about it a year ago. I didn't |>get a response and it hasn't been fixed. I am now using JR-Comm. Most VT220's and VT320's, while in a mode other than VT220, will automatically switch themselves into VT220 mode when they receive a TERMINAL/INQUIRE message. I'm not sure it is a bug, but it could be that only VT220 mode HAS the inquire message, so it automatically switches to that mode when it sees the message. It seems to be a hack to do the inquire properly, or just a firmware bug. Again, I'm not sure but it's definitely not a problem with Handshake. Btw, I have found JR-comm's VTxxx modes to be useless for serious work. I suggest going back to Handshake and using Vt220 or just not doing an INQUIRE. |>Earle Kris +-----------------------------------------------------------------------------+ |Kriston J. Rehberg, Student Consultant, SUNY Binghamton Computer Services | |consp03@BINGSUNS.CC.BINGHAMTON.EDU +---------------------------+ |consp03@BINGVAXU.CC.BINGHAMTON.EDU |Opinions expressed here are| |CONSP03@BINGVAXA.CC.BINGHAMTON.EDU |my own and do not represent| | |those of this organization | +-----> Only Amiga makes it possible! <-----------+--------------------- ;-b -+
kms@ecsvax.uncecs.edu (Ken Steele) (06/09/91)
In article <c506634.3354@umcvmb.missouri.edu>, c506634@umcvmb.missouri.edu (Eric Edwards) writes: > > Does Handshake support extended length packets in file transfers > > with Kermit? Even though I execute a 'set send packet-length > > The kermit protocal built into Handshake 2.20c does not support long > packtes. However, Handshake does support external protocal libraries. > XPRKermit DOES support long packets. > > Eric Edwards: c506634 @ "I say we take off and nuke the entire site > Inet: umcvmb.missouri.edu from orbit. It's the only way to be sure." > Bitnet: umcvmb.bitnet -- Sigourney Weaver, _Aliens_ Thanks for the information. I grabbed xprkermit 1.5 from the archive at abcfd20, but have been unable to get it to work with Handshake 2.20c. Please read further if you have any suggestions. Here is what I have tried so far. I installed xprkermit.library in LIBS:. After starting Handshake, I choose external protocol from the menu, and then attempt to change the transfer parameters. Handshake throws up a sequence of boxes requesting string input but most of the boxes won't accept ANY input. After the requester series is finished, Handshake locks the machine and the only exit is a 3-finger reboot. The above happens no matter how I respond to the requesters, whether kermit is running on the other machine or not, whether I am connected to another machine or not, whether the modem is on or not. Variation 2: I create an ENV: variable called xprkermit which contains 'Cram: OTN,P1024,B3'(i.e., cd ram: options text no, packet size 1024, checkblock 3). I initiate a transfer, but the previous settings are not used. (Same settings on the mainframe.) Variation 3: I create the ENV: variable called xprkermit and attempt to change the transfer settings from Handshake's menu. I get similar effects to the original attempt to use the menu system except I am able to get back to Handshake's menus under some circumstances. If you are successfully using handshake 2.20c with xprkermit 1.5 then please let me know what I should be doing. Thanks -- Ken Steele Dept. of Psychology kms@ecsvax.bitnet Mars Hill College kms@ecsvax.uncecs.edu Mars Hill, NC 28754 {some big name site}!mcnc!ecsvax!kms
ake@dayton.saic.com (Earle Ake) (06/09/91)
In article <2969@public.BTR.COM>, thad@public.BTR.COM (Thaddeus P. Floryan) writes: > You say "Vax" but I suspect you mean a Vax running VMS. > > What's doing-you-in is a "SET TERM/INQUIRE". > > Check your LOGIN.COM for that (^^^^^^^^^^) and remove it. > > If you're unfortunate enough to have a system where the SET TERM/INQUIRE is > in the system-wide LOGIN.COM, then either ask your site admin to remove that > from that file OR to alter your UAF entry to NOT execute the system-wide > LOGIN.COM and to just execute your personal LOGIN.COM instead. The systems that have 'SET TERM/INQUIRE' have it there for a reason. If you remove it and then try to use an application that uses the SMG (Screen ManaGement) service, it might fail. Anymore by default the terminal lines are set 'unknown' and the 'set term/inquire' is used to determine what type of terminal you have and set the terminal settings properly. The REAL problem is REAL vt100 emulators should know how to handle that escape sequence properly. Handshake is returning the correct string but in the process is resetting itself to a VT220 ALL the time! The solution is to have Eric fix the code not remove the 'set term/inquire' from the login.com! Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake
ridder@elvira.enet.dec.com (Hans Ridder) (06/09/91)
In article <1991Jun8.194853.22312@newserve.cc.binghamton.edu> consp03@bingsuns.cc.binghamton.edu (Kriston J. Rehberg) writes: >In article <1991Jun6.101336.1659@dayton.saic.com>, ake@dayton.saic.com >(Earle Ake) writes: >|> If you use the command 'set terminal/inquire' on the VAX, the >|>VAX sends out an escape sequence and the terminal reports back what type >|>it is with an escape sequence. The problem is Handshake also sets >|>itself to VT220 mode 'for you'. It shouldn't do this and it is a bug. >|>Send a message to Eric and > ^^^^^^^^^^^ > nope, it's not a bug! > >Most VT220's and VT320's, while in a mode other than VT220, will >automatically switch themselves into VT220 mode when they receive a >TERMINAL/INQUIRE message. Well, this isn't a feature of the VTxxx terminals. It's been a while since I looked at what VMS sends during a SET TERMINAL/INQUIRE, so it's possible that VMS thinks it knows better, and changes you to the terminal's "native" mode, but I've never heard of it. I'll check it when I'm in the office. >I'm not sure it is a bug, but it could be that only VT220 mode HAS the >inquire message, so it automatically switches to that mode when it sees >the message. It seems to be a hack to do the inquire properly, or just >a firmware bug. Again, I'm not sure but it's definitely not a problem >with Handshake. All VT terminals (from VT52 to VT1300) have an inquire ability, none of them change modes when asked what they are (unless they're broken.) If anything is going on, it's either a bug in Handshake, or VMS is slamming on the terminal. In any case, Handshake should do what a real VTxxx does, since that's what it's supposed to be emulating, right? If a real VTxxx doesn't exhibit the behavior, then Handshake is broken. >|>Earle >Kris -hans ------------------------------------------------------------------------ Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
thad@public.BTR.COM (Thaddeus P. Floryan) (06/09/91)
In article <1991Jun8.212156.1663@dayton.saic.com> ake@dayton.saic.com (Earle Ake) writes: >[...] > The systems that have 'SET TERM/INQUIRE' have it there for a reason. >If you remove it and then try to use an application that uses the SMG (Screen >ManaGement) service, it might fail. Anymore by default the terminal lines are >set 'unknown' and the 'set term/inquire' is used to determine what type of >terminal you have and set the terminal settings properly. > > The REAL problem is REAL vt100 emulators should know how to handle that >escape sequence properly. Handshake is returning the correct string but in the >process is resetting itself to a VT220 ALL the time! The solution is to have >Eric fix the code not remove the 'set term/inquire' from the login.com! >[...] The REAL problem is NOT how DEC VT2?? and VT3?? terminals and clones (both hardware and software) operate. Handshake mimics a real DEC VT2?? properly. I have "real" DEC VT100, DEC VT102, DEC VT220, and DEC VT340 terminals at my office and can see how they are definitely braindamaged. A REAL DEC VT220, operated in DEC VT100 mode, will shift to VT2?? mode after a "SET TERM/INQUIRE" under VMS 4.3, 4.4, 4.7, and all 5.*. The situation got to be so frustrating that I fixed everyone's LOGIN.COM files on my systems (yeah, multiple VAXen running VMS (ugh)) to simply set the term mode to VT100 upon login. This works just fine with SMG and hasn't caused ANY problems in over 5 years for anyone including my timesharing customers (among whom can be found the world's largest banks). The "problem" is that the DEC terminals, upon receipt of the inquiry code, indicate they're a (for example) DEC VT220 in VT100 mode and then setup to VT200 mode; though it's been a while since I've connected DLM test equipment to check this, it's my recollection that VMS itself instructs the terminal to enter VT200 mode even though the user had the terminal set in VT100 mode. IN ANY EVENT, it is NOT a problem with Handshake (in this regards); Handshake does exactly what DEC's own terminals do in this respect. Not only that, EVERY VT200 clone terminal I've tested over the years (e.g. Liberty, Falco, et al) does the same annoying thing ONLY on a VMS system. Why do you think VMS is colloquially known as the Vomit Making System? :-) Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
thad@public.BTR.COM (Thaddeus P. Floryan) (06/09/91)
In article <2996@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >[...] >I have "real" DEC VT100, DEC VT102, DEC VT220, and DEC VT340 terminals at my >office and can see how they are definitely braindamaged. >[...] What I meant by that statement is that if the terminal is IN, say, VT100 mode, then that is how the terminal should report itself. The concept of "preferences" seems to be lost at certain companies. If the user wants to be in VT100 mode, an application (or operating system) shouldn't second-guess the user's intents, especially if the user is coming in over a network from a system that still thinks the user is on a VT100 but when the user returns to the first system the terminal was "gratuiously" set by VMS to a VT200 which now breaks applications on the first system which still believes the terminal to be in VT100 mode. (Huh? :-) The "SET TERM/INQUIRE" shouldn't alter the user's preferences as it presently does. Of course, what could one expect from a company that's more than three years late with TCP/IP support in its DECnet product? (Re: DECnet Phase V promised in 1988; this is now 1991 and rumors suggest Phase V "may" be available by the end of this month (we'll see)). With increasing frequency over the 25+ years I've used DEC products, I'm drawn to the conclusion that DEC isn't always dealing with a full deck. :-) Apologies to my friends and acquaintances who are employed by DEC; the real "problem" is rooted back east in MA in the office of a certain individual. Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
consp03@bingsuns.cc.binghamton.edu (Kriston J. Rehberg) (06/10/91)
In article <3326@shodha.enet.dec.com>, ridder@elvira.enet.dec.com (Hans Ridder) writes: |>Well, this isn't a feature of the VTxxx terminals. It's been a while |>since I looked at what VMS sends during a SET TERMINAL/INQUIRE, so it's |>possible that VMS thinks it knows better, and changes you to the |>terminal's "native" mode, but I've never heard of it. I'll check it |>when I'm in the office. It does it whenever it receives an inquire message. Incidently, when I set the terminal type to VT220 in SunOS or UNIX, Handshake (and all VT220's I have used) switch themselves to VT220 no matter what mode they're in, so you be the judge. I test about a hundred VT220s twice a week, and that's what happens! |>All VT terminals (from VT52 to VT1300) have an inquire ability, none of |>them change modes when asked what they are (unless they're broken.) If |>anything is going on, it's either a bug in Handshake, or VMS is slamming |>on the terminal. In any case, Handshake should do what a real VTxxx |>does, since that's what it's supposed to be emulating, right? If a real |>VTxxx doesn't exhibit the behavior, then Handshake is broken. Yes, you are right about the inquire message. Sorry about that. I agree with you, but since real VTxxx terminals exhibit this behavior (about 85% of them do) then Handshake is doing its job. Even the VM systems when you specify VT220 and you're on VT100 mode (helpful for switching the enter/return keys) the terminal will switch itself to VT220 for you. |>-hans Kris +-----------------------------------------------------------------------------+ |Kriston J. Rehberg, Student Consultant, SUNY Binghamton Computer Services | |consp03@BINGSUNS.CC.BINGHAMTON.EDU +---------------------------+ |CONSP03@BINGVAXA.BITNET |Opinions expressed here are| | |my own and do not represent| | Summertime, summertime. Fun, fun, summertime...|those of this organization | +-----> Only Amiga makes it possible! <-----------+--------------------- ;-b -+
coburn@clo.enet.dec.com (John T. Coburn) (06/10/91)
In article <2996@public.BTR.COM>, thad@public.BTR.COM (Thaddeus P. Floryan) writes...
:
:The REAL problem is NOT how DEC VT2?? and VT3?? terminals and clones (both
:hardware and software) operate. Handshake mimics a real DEC VT2?? properly.
:
:I have "real" DEC VT100, DEC VT102, DEC VT220, and DEC VT340 terminals at my
:office and can see how they are definitely braindamaged.
:
:A REAL DEC VT220, operated in DEC VT100 mode, will shift to VT2?? mode after
:a "SET TERM/INQUIRE" under VMS 4.3, 4.4, 4.7, and all 5.*.
:
This happens because the SET TERM/INQ code tells the VT2xx to switch to VT200,
7bit controls mode. This is the real problem.. Handshake is just doing what it
is told to do.
[text removed]
:The "problem" is that the DEC terminals, upon receipt of the inquiry code,
:indicate they're a (for example) DEC VT220 in VT100 mode and then setup to
:VT200 mode; though it's been a while since I've connected DLM test equipment to
:check this, it's my recollection that VMS itself instructs the terminal to
:enter VT200 mode even though the user had the terminal set in VT100 mode.
:
This is essentially correct. If you want to be in VT100 mode then you need to
return a VT100 identification sequence to keep SET TERM/INQ from telling you to
change your mode. This may be where Handshake needs to fixed.
:IN ANY EVENT, it is NOT a problem with Handshake (in this regards); Handshake
:does exactly what DEC's own terminals do in this respect. Not only that,
:EVERY VT200 clone terminal I've tested over the years (e.g. Liberty, Falco,
:et al) does the same annoying thing ONLY on a VMS system.
:
:Why do you think VMS is colloquially known as the Vomit Making System? :-)
:
I disagree - at least VMS is usable. Maybe I'm biased having grown up on RT11,
RSX-11M and CPM. Amigas and VMS forever. :-)
:Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
--------------------------------------------------------------------------------
John Coburn !Email:
Digital Equipment Corporation ! coburn@clovax.enet.dec.com -or-
Digital Services, Consulting Services ! coburn%clovax.enet@decwrl.dec.com
Cleveland, Ohio ! ...!decwrl!clovax.enet!coburn
================================================================================coburn@clo.enet.dec.com (John T. Coburn) (06/10/91)
In article <2997@public.BTR.COM>, thad@public.BTR.COM (Thaddeus P. Floryan) writes... :In article <2996@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: :>[...] :>I have "real" DEC VT100, DEC VT102, DEC VT220, and DEC VT340 terminals at my :>office and can see how they are definitely braindamaged. :>[...] : :What I meant by that statement is that if the terminal is IN, say, VT100 mode, :then that is how the terminal should report itself. : Agreed. :The concept of "preferences" seems to be lost at certain companies. : :If the user wants to be in VT100 mode, an application (or operating system) :shouldn't second-guess the user's intents, especially if the user is coming :in over a network from a system that still thinks the user is on a VT100 but :when the user returns to the first system the terminal was "gratuiously" set :by VMS to a VT200 which now breaks applications on the first system which :still believes the terminal to be in VT100 mode. (Huh? :-) : :The "SET TERM/INQUIRE" shouldn't alter the user's preferences as it presently :does. Also, agreed - SET TERM/INQUIRE is braindamaged in several ways. : :Of course, what could one expect from a company that's more than three years :late with TCP/IP support in its DECnet product? (Re: DECnet Phase V promised :in 1988; this is now 1991 and rumors suggest Phase V "may" be available by the :end of this month (we'll see)). No comment. :-) : :With increasing frequency over the 25+ years I've used DEC products, I'm drawn :to the conclusion that DEC isn't always dealing with a full deck. :-) : :Apologies to my friends and acquaintances who are employed by DEC; the real :"problem" is rooted back east in MA in the office of a certain individual. : Probably more than one individual. :Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ] -------------------------------------------------------------------------------- John Coburn !Email: Digital Equipment Corporation ! coburn@clovax.enet.dec.com -or- Digital Services, Consulting Services ! coburn%clovax.enet@decwrl.dec.com Cleveland, Ohio ! ...!decwrl!clovax.enet!coburn ================================================================================
ridder@elvira.enet.dec.com (Hans Ridder) (06/11/91)
In article <2996@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >The REAL problem is NOT how DEC VT2?? and VT3?? terminals and clones (both >hardware and software) operate. Handshake mimics a real DEC VT2?? properly. Never run Handshake, but I don't think so.... (see below) >I have "real" DEC VT100, DEC VT102, DEC VT220, and DEC VT340 terminals at my >office and can see how they are definitely braindamaged. > >A REAL DEC VT220, operated in DEC VT100 mode, will shift to VT2?? mode after >a "SET TERM/INQUIRE" under VMS 4.3, 4.4, 4.7, and all 5.*. I just tested this on a *real* VT220, VT320, and a VT330. When set to VT100 mode, they *stay* in VT100 mode after a SET TERM/INQUIRE. Note that you have to select "VT100 ID" when in VT100 mode. If you leave it at VT220 then yes, VMS, for whatever reason, changes the terminal into its native mode. >The situation got to be so frustrating that I fixed everyone's LOGIN.COM files >on my systems (yeah, multiple VAXen running VMS (ugh)) to simply set the term >mode to VT100 upon login. Looks to me like you didn't need to.... >The "problem" is that the DEC terminals, upon receipt of the inquiry >code, indicate they're a (for example) DEC VT220 in VT100 mode and then >setup to VT200 mode; though it's been a while since I've connected DLM >test equipment to check this, it's my recollection that VMS itself >instructs the terminal to enter VT200 mode even though the user had the >terminal set in VT100 mode. The terminals send back whatever ID you tell them to. If you want to be a VT100, then set the ID to VT100. Yes, I agree that it doesn't make much sense for them to say they're a VT220 when set to VT100 mode...so change the ID. >IN ANY EVENT, it is NOT a problem with Handshake (in this regards); Handshake >does exactly what DEC's own terminals do in this respect. Not only that, >EVERY VT200 clone terminal I've tested over the years (e.g. Liberty, Falco, >et al) does the same annoying thing ONLY on a VMS system. Well, if Handshake doesn't allow you to set the ID, then it should be sending a VT100 ID when in VT100 mode. In that case VMS doesn't mess with the terminal. So, if Handshake is sending a VT220 ID when in VT100 mode, and there's no way to change it, I say it's broken. >Why do you think VMS is colloquially known as the Vomit Making System? :-) Dunno, never heard that one before. And we usually know most of those *clever* sayings. Heck, we usually make them up! >Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ] -hans ------------------------------------------------------------------------ Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
ridder@elvira.enet.dec.com (Hans Ridder) (06/11/91)
In article <2997@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >In article <2996@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >>I have "real" DEC VT100, DEC VT102, DEC VT220, and DEC VT340 terminals at my >>office and can see how they are definitely braindamaged. > >What I meant by that statement is that if the terminal is IN, say, VT100 mode, >then that is how the terminal should report itself. Agreed. >If the user wants to be in VT100 mode, an application (or operating system) >shouldn't second-guess the user's intents, especially if the user is coming >in over a network from a system that still thinks the user is on a VT100 but >when the user returns to the first system the terminal was "gratuiously" set >by VMS to a VT200 which now breaks applications on the first system which >still believes the terminal to be in VT100 mode. (Huh? :-) What's actually happening here is that when VMS hears that the terminal is, say a VT220, it sends a sequence to tell the terminal to go into "Level 2, 7 bit controls" mode (or I think "Level 2, 8 bit controls" if the terminal port is set to "8 bits".) It's mostly interested in the 7-bit/8-bit part to make sure the terminal and the system have the same idea about how many bits to use. This has the unfortunate side effect of changing you to VT220 mode... >The "SET TERM/INQUIRE" shouldn't alter the user's preferences as it presently >does. Just to be sure no one missed this, if set to VT100 mode *and* VT100 ID, then SET TERM/INQUIRE doesn't mess with your preferences. >Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ] ------------------------------------------------------------------------ Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO
thad@public.BTR.COM (Thaddeus P. Floryan) (06/11/91)
In article <3339@shodha.enet.dec.com> ridder@elvira.enet.dec.com (Hans Ridder) writes: >[...] >I just tested this on a *real* VT220, VT320, and a VT330. When set to >VT100 mode, they *stay* in VT100 mode after a SET TERM/INQUIRE. Note >that you have to select "VT100 ID" when in VT100 mode. If you leave it >at VT220 then yes, VMS, for whatever reason, changes the terminal into >its native mode. >[...] Now THAT (selection of a "VT100 ID") is news to me and some 300 other people (over the years) at my company. We've been using DEC computers and terminals for a long time (just celebrated our company's 19th anniversary last week (June 3, 1972)) and NONE of us noticed that. OK, I'm taking in DLM (Data Line Monitor) test equipment to my office tomorrow and will check this out (besides re-reading the VT2?? and VT3?? manuals and perusing their SETUP screens). Sheesh, with 3 DEC-20, four VAXen, and umpteen DEC terminals one would've thought this would have been noticed before; perhaps the EPROM code in our terminals is o-l-d. OOPS, correct that to be two DEC-20; just remember one 2060 was let-go last week along with Cisco's and Stanford's (though I did keep the nameplate). Sigh, approaching the end of another era. 'Sfunny, though, I never had problems with the SAME terminals operated on UNIX systems (with their equivalent of a SET TERM/INQUIRE (on some systems)). Hmmmm. Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
hassinger@lmrc.uucp (Bob Hassinger) (06/13/91)
This issue of the terminal switching to 200 mode when it gets an inquire sequence sounds familiar. It has been long enough that I may be recalling incorrectly but I think my early VT240 did this. But as I recall I later got a ROM upgrade installed that fixed that and several other type ID and emulation related problems. The 240 is gone now so I can't check it but I don't think I have seen it happen with my 340. I am note sure the answer is the same for the 220 as it is for the 240, but I think it may be. Basically, Handshake may be faithfully emulating out of date firmware. In other words, in discussing what you observe VTxxx's doing, it may be a good idea to include the version number of your firmware (generally shown on the setup screen). Bob Hassinger
thad@public.BTR.COM (Thaddeus P. Floryan) (06/13/91)
In article <13536@lmrc.uucp> hassinger@lmrc.uucp (Bob Hassinger) writes: >This issue of the terminal switching to 200 mode when it gets an inquire >sequence sounds familiar. It has been long enough that I may be recalling >incorrectly but I think my early VT240 did this. But as I recall I later got a >ROM upgrade installed that fixed that and several other type ID and emulation >related problems. The 240 is gone now so I can't check it but I don't think I >have seen it happen with my 340. > >I am note sure the answer is the same for the 220 as it is for the 240, but I >think it may be. Basically, Handshake may be faithfully emulating out of >date firmware. > >In other words, in discussing what you observe VTxxx's doing, it may be a good >idea to include the version number of your firmware (generally shown on the >setup screen). As I promised to do, I *did* check the setup screens to see if there was something like "SET ID". Problems with one of our VAXen didn't leave me much free time today, but while rebooting the system I glanced through a DEC VT340 manual that was in the computer room. The index of the manual listed a page reference for "device attributes" to which I quickly turned, and found only an obscure reference embedded in one sentence, and NO clue(s) how to effect it. Finally had to flip the manual page-by-page until I stumbled upon the "General" setup screen when the sequence {340,320,240,220,102,101,100, etc) caught my eye and, yes, there is a way to cause the terminal to return different ID codes (at least per the docs). For fun, I told 5 people that they COULD change the ID string from the SETUP, and to please try it on their own. Not ONE was able to intuitively find that menu selection on any SETUP menu after several minutes' trying. I was called away on other business and didn't try this myself (in particular, to see if it actually works! :-), but will do so tomorrow. For reference, I recall the operative phrase to be "DEVICE ATTRIBUTES STRING" on the VT340; will have to check it on the VT2?? also. If it does operate as documented, then problem solved (at least for a real DEC VT2??/3??). But the menu setup option is sure not "easy" to locate, and the lack of adequate cross-referencing in DEC's manuals is frustrating (much like the lack of any "SEE ALSO" (per UNIX' docs) in any VMS manuals). A completely configurable terminal (or emulator thereof, like Handshake) "should" be able to alter all terminal responses as needed; if it does, then I'll stand corrected. Will test this using VMS 4.7, 5.1, and 5.3 Thanks to everyone for their responses in this regards. Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
ridder@elvira.enet.dec.com (Hans Ridder) (06/14/91)
In article <3054@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes: >As I promised to do, I *did* check the setup screens to see if there was >something like "SET ID". > >The index of the manual listed a page reference for "device attributes" to >which I quickly turned, and found only an obscure reference embedded in one >sentence, and NO clue(s) how to effect it. Whoops, I think it's clear I've been working here to long. *I* know that a "device arributes response" is the same thing as an "ID", doesn't everyone? ;-) Sorry, I should have been more specific. >For reference, I recall the operative phrase to be "DEVICE ATTRIBUTES STRING" >on the VT340; will have to check it on the VT2?? also. That's the word. I didn't want to turn this into comp.sys.dec-terminals, but since we're talking about Handshake on the Amiga: On the VT220, when you select VT100 mode on the General Set-Up screen, another option pops up which lets you select VT100 ID, VT102 ID, and VT220 ID. On the VT320 also on the General Set-Up screen, just to the right of the "mode" selection there is a box for choosing the ID (with a few more choices.) On the VT330's General Set-Up screen, just below the "Terminal Mode" setting, there is a "Device Attributes Response" setting. This is a technical obfuscation of "ID". The actual name of the escape sequence (actually a "control sequence,") used for the request and the response is "Device Attributes," or "DA." >If it does operate as documented, then problem solved (at least for a real >DEC VT2??/3??). But the menu setup option is sure not "easy" to locate, and >the lack of adequate cross-referencing in DEC's manuals is frustrating (much >like the lack of any "SEE ALSO" (per UNIX' docs) in any VMS manuals). In no way am I trying to defend the organization of the VMS manuals, but there's lots of times I've searched for *days* through the UNIX manuals pages looking for something I *knew* was there. Coming from TOPS-20 (what's that?), I figure it has more to do with what you're used to. Remember the old 1.0 RKM? Echhh! Good documentation is hard to write. >Thanks to everyone for their responses in this regards. Glad to be of help! >Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ] -hans ------------------------------------------------------------------------ Hans-Gabriel Ridder Digital Equipment Corporation ridder@elvira.enet.dec.com Customer Support Center ...decwrl!elvira.enet!ridder Colorado Springs, CO