dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/09/88)
I use Microport System V/AT to dial up and its termcap entry that I
use is:
sy|uport|uport generic ansi standard terminal:\
:am:bs:xt:\
:co#80:li#24:\
:al=\E[L:cd=\E[J:ce=\E[K:cl=\E[H\E[J:\
:cm=\E[%i%d;%dH:dc=\E[P:dl=\E[M:ho=\E[H:\
:kb=\b:kd=\E[B:kh=\E[H:kl=\E[D:\
:up=\E[A:\
:kr=\E[C:ku=\E[A:nd=\E[C:\
:us=\E[4m:ue=\E[m:\
:so=\E[7m:se=\E[m:\
:md=\E[1m:\
:mr=\E[7m:\
:me=\E[m:
This works nicely with 4.3BSD. But VMS editors just splutter at me
(even if I do $ set terminal/ansi etc.) and mess up my screen. Does
anybody know how to do this?
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesikarl@ddsw1.UUCP (Karl Denninger) (02/11/88)
In article <2058@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >I use Microport System V/AT to dial up and its termcap entry that I >use is: > >sy|uport|uport generic ansi standard terminal:\ > :am:bs:xt:\ > :co#80:li#24:\ > :al=\E[L:cd=\E[J:ce=\E[K:cl=\E[H\E[J:\ > :cm=\E[%i%d;%dH:dc=\E[P:dl=\E[M:ho=\E[H:\ > :kb=\b:kd=\E[B:kh=\E[H:kl=\E[D:\ > :up=\E[A:\ > :kr=\E[C:ku=\E[A:nd=\E[C:\ > :us=\E[4m:ue=\E[m:\ > :so=\E[7m:se=\E[m:\ > :md=\E[1m:\ > :mr=\E[7m:\ > :me=\E[m: > >This works nicely with 4.3BSD. But VMS editors just splutter at me >(even if I do $ set terminal/ansi etc.) and mess up my screen. Does >anybody know how to do this? Forget it - it's probably easier to buy a VT220 clone than fix it. VMS doesn't want to see ANSI, they want to see their idea of ANSI -- which contains proprietary extensions, etc. For example, they define a 'inquiry' sequence which the terminal is supposed to respond to (the sequence response identifies the type of terminal, enhancements in it if any [ie: graphics], etc.) You're also contending with the fact that the ANSI emulation which uport uses in the console driver is not quite playing with a full deck. That is, things like scroll regions don't work quite right (2.3.0 is better but not quite right -- earlier versions had major shortcomings). The biggest problem with VAX/VMS and terminals (in my opinion) is that you can't make your own termcap entries. The software knows of only a few terminals -- all DEC products. (Ever wonder why there's such a market for VT100/VT220 look-alike terminals? Now you know!) Your only solution would be to write a filter routine which you insert in your terminal program (or pipe to/from it) that translates *all* the DEC control codes to what uport wants to see. Yuck. ------- Karl Denninger | Data: +1 312 566-8912 Macro Computer Solutions, Inc. | Voice: +1 312 566-8910 ...ihnp4!ddsw1!karl | "Quality solutions for work or play"
tihor@acf4.UUCP (Stephen Tihor) (02/11/88)
Wrong. EVE and the TPU based EDT emulator work ok on terminals falling between raw ANSI minimimals and true DEc emulators if you define them properly.
hildum@iris.ucdavis.edu (Eric Hildum) (02/12/88)
In article <719@ddsw1.UUCP> karl@ddsw1.UUCP (Karl Denninger) writes: >The biggest problem with VAX/VMS and terminals (in my opinion) is that you >can't make your own termcap entries. The software knows of only a few >terminals -- all DEC products. (Ever wonder why there's such a market for >VT100/VT220 look-alike terminals? Now you know!) > The VAX/VMS Run-Time Library Routines Reference Manual describes in great detail how to support other manufacturers terminals. Check section 3.10 (pages 3-27 through 3-49) for the proper method of support. For those people interested in developing code using the screen management routines, the bulk of chapter three is devoted to explaining the routines and how to PROPERLY use them. Too often I have seen stupidly written code for VMS. Now I understand why, the engineers for these companies are spending too much time complaining about why VMS doesn't do what they want, and not enough time learning that, in fact, the solution is already there. >Your only solution would be to write a filter routine which you insert in >your terminal program (or pipe to/from it) that translates *all* the DEC >control codes to what uport wants to see. Yuck. > >------- >Karl Denninger | Data: +1 312 566-8912 >Macro Computer Solutions, Inc. | Voice: +1 312 566-8910 >...ihnp4!ddsw1!karl | "Quality solutions for work or play" dehildum@ucdavis.ucdavis.edu (Internet) dehildum@ucdavis.bitnet (BITNET) ucbvax!ucdavis!dehildum (uucp)
pack@acdpyr.ucar.edu (Dan Packman) (02/13/88)
Although it is possible to include termtable information for non-ansi terminals, all DEC software does not use this interface. For instance, edt is hard-wired to ansi, dcl doesn't use termtable to update the command line editor. Mail does use the information to clear the terminal screen. Does anyone know if DEC will use termtable/smgterm interface in edt/tpu and other programs in the future? Does anyone have a tested version of the termtable entry for the wyse50?
dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/13/88)
In article <1112@ucdavis.ucdavis.edu> hildum@iris.UUCP (Eric Hildum) writes: >The VAX/VMS Run-Time Library Routines Reference Manual describes in >great detail how to support other manufacturers terminals.... >...the engineers for these companies are spending too much time >complaining about why VMS doesn't do what they want, and not enough >time learning that, in fact, the solution is already there. Great! Please post the solution here. I would greatly like to use EDT with my Microport System AT terminal emulation. I posted its termcap entry in my first message. Thanks. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
karl@ddsw1.UUCP (Karl Denninger) (02/16/88)
In article <1112@ucdavis.ucdavis.edu> hildum@iris.UUCP (Eric Hildum) writes: >In article <719@ddsw1.UUCP> karl@ddsw1.UUCP (Karl Denninger) writes: $>The biggest problem with VAX/VMS and terminals (in my opinion) is that you $>can't make your own termcap entries. The software knows of only a few $>terminals -- all DEC products. (Ever wonder why there's such a market for $>VT100/VT220 look-alike terminals? Now you know!) >The VAX/VMS Run-Time Library Routines Reference Manual describes in >great detail how to support other manufacturers terminals. Check >section 3.10 (pages 3-27 through 3-49) for the proper method of >support. Ok. Do the standard VAX utilities (ie: EDIT) work with these definitions (I am thinking of something similar to curses here, where the user can redefine things if their terminal is not 'standard')? I've never seen it... (where's that 'gold' key on my ADM3A?!) >For those people interested in developing code using the screen >management routines, the bulk of chapter three is devoted to >explaining the routines and how to PROPERLY use them. This may be true -- but I don't want to WRITE programs, I want to use the items which came with the operating system! >Too often I have seen stupidly written code for VMS. Now I understand >why, the engineers for these companies are spending too much time >complaining about why VMS doesn't do what they want, and not enough >time learning that, in fact, the solution is already there. The solution is not there if you want to simply use the DEC-supplied utilities. I just logged into the VAX that I have access to, and looked around (to make sure I was not having a fit of dyslexia). As expected (the last time I did a close exam was VMS V3) there was no mention of any device type other than DEC and (supposedly) ANSI. My ANSI emulator couldn't quite handle the 'Ansi', though... and there was no way to change VMS's idea of what my ANSI terminal looks like for use with EDIT, for example. $>Your only solution would be to write a filter routine which you insert in $>your terminal program (or pipe to/from it) that translates *all* the DEC $>control codes to what uport wants to see. Yuck. The solution, while I admit is ugly, will work. Show me the easy way. I would love to be able to define the 'look and feel' of my terminal to a VMS system, but haven't seen it done yet. Remember, the goal is to make it work with the DEC-supplied software and a reasonable percentage of applications software. ------ Karl Denninger | Data: +1 312 566-8912 Macro Computer Solutions, Inc. | Voice: +1 312 566-8910 ...ihnp4!ddsw1!karl | "Quality solutions for work or play"
dave@wsccs.UUCP (Dave E Martin "VAX Headroom") (02/23/88)
> The biggest problem with VAX/VMS and terminals (in my opinion) is that you > can't make your own termcap entries. The software knows of only a few > terminals -- all DEC products. (Ever wonder why there's such a market for > VT100/VT220 look-alike terminals? Now you know!) Yes, you can define your own terminals with VMS. Any utility that uses SMG routines and don't check speficially for ANSI terminals will work. See the files: sys$system:termtable.txt, sys$system:termtable.exe, and sys$system:smgterms.txt this file contains the definitions for terminals and (in my opinion) is MUCH more understandable than the UNIX equivalent. after defining your terminal in this file you need to run a program to "compile" it. See the first part of the SMG documentation for details. users can also have their own private copies of the terminal database if they want to define something and don't (or can't) put it in the system termtable. +-----------------------------------------------------------------------------+ | | Dave E Martin | DISCLAIMER: Been Cancelled | | /\ | "...between the streets of | $ opinion/mine/noUinTech | | / \ . /\ | Dallas, and the beaches of |----------------------------| | / \/ \/\/ \ | Miami ... THIS was Max | ...!ihnp4!utah-cs!utah-gr! | | / U i n T e c h \ | Headroom's finest hour." | uplherc!sp7040!obie! | | | --Max Headroom | wsccs!net23.dnet!dave | +-----------------------------------------------------------------------------+
terry@wsccs.UUCP (terry) (02/26/88)
In article <719@ddsw1.UUCP>, karl@ddsw1.UUCP (Karl Denninger) writes: > In article <2058@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > >I use Microport System V/AT to dial up and its termcap entry that I > >use is: [a termcap entry nobody wants is deleted here] > >This works nicely with 4.3BSD. But VMS editors just splutter at me > >(even if I do $ set terminal/ansi etc.) and mess up my screen. Does > >anybody know how to do this? Don't listen to him... the answer is "yes". > Forget it - it's probably easier to buy a VT220 clone than fix it. Demonstrably false... read on: > VMS doesn't want to see ANSI, they want to see their idea of ANSI > -- which contains proprietary extensions, etc. For example, they define a > 'inquiry' sequence which the terminal is supposed to respond to (the > sequence response identifies the type of terminal, enhancements in it if > any [ie: graphics], etc.) If you are not talking about the ^Z, then the inquiry sequence *IS* ANSI standard. You may also notice that ANSI terminals have 24 lines and what uPort and SCO are calling ANSI isn't, for this as well as a grundle of other reasons; you only hit the high points below... > You're also contending with the fact that the ANSI emulation which uport > uses in the console driver is not quite playing with a full deck. That is, > things like scroll regions don't work quite right (2.3.0 is better but not > quite right -- earlier versions had major shortcomings). > The biggest problem with VAX/VMS and terminals (in my opinion) is that you > can't make your own termcap entries. The software knows of only a few > terminals -- all DEC products. (Ever wonder why there's such a market for > VT100/VT220 look-alike terminals? Now you know!) That's a lie. There is a terminal database on VMS. It's called SYS$SYSTEM:SMGTERMS.TXT. It just that 1) a terminal has to be able to do at LEAST what a VT100 can do (AM, no SG#1, no UG#1, etc) to be able to live up to being defined in this file... it makes too many assumptions, and 2) a lot of programs for VMS from commercial people (I don't count DEC, as that is nepotism, not commercialism) assume a minimum of a vt100 and then just go off and emit the sequences themselves, due to porting considerations becoming too ugly otherwise. > Your only solution would be to write a filter routine which you insert in > your terminal program (or pipe to/from it) that translates *all* the DEC > control codes to what uport wants to see. Yuck. [sorta commercial... ignore if necessary to avoid sending me nasty mail] How about a VT100 emulator for the uPort system? We sell a dandy one which even does box-drawing graphics and scroll regions... even if the terminal doesn't have the graphics, we can adequately fake it for the VT100 and our 9 other emulations. Heck! We even emulate _out_ a VMS system. [end commercial... it isn't often I get to prosyletize :^)] Or there is a public domain one (don't know how good it is) which is avaiable from the archives... so there IS an alternative or five. | Terry Lambert UUCP: ...!decvax!utah-cs!century!terry | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |
terry@wsccs.UUCP (terry) (02/26/88)
In article <1112@ucdavis.ucdavis.edu>, hildum@iris.ucdavis.edu (Eric Hildum) writes: > In article <719@ddsw1.UUCP> karl@ddsw1.UUCP (Karl Denninger) writes: > >The biggest problem with VAX/VMS and terminals (in my opinion) is that you > >can't make your own termcap entries. The software knows of only a few > >terminals -- all DEC products. (Ever wonder why there's such a market for > >VT100/VT220 look-alike terminals? Now you know!) > > [some references which don't explain my question deleted] > Too often I have seen stupidly written code for VMS. Now I understand > why, the engineers for these companies are spending too much time > complaining about why VMS doesn't do what they want, and not enough > time learning that, in fact, the solution is already there. Honest true? And tell me, how DO I ask SMG$ what sequence I should expect the terminal to send... for instance, how do I ask it what the help key sends? Sure, SMG$ will RECOGNIZE it for me, but I don't want it to... I want to do it in a reasonable amount of time, after all, as this is a realtime application. I can just use tgets() under UNIX; how do I do the same under VMS??? Before you rag on me to consult my manual, I can assure you that after examining your references, I went back and looked and the incantation with 12 arguments still wasn't there... I could ask it about the sequence to use to clear the screen, etc, but *only* _OUTPUT_ oriented stuff. I have been told that I should pretend they are there and the linker would resolve it... no dice. I have access to the source on fische. It ain't there, buddy. DEC makes mistakes (*BLASPHEMY!* Kill the infidel!)... for instance look at the docs in the IO Services manual where the QIO$ for setting tty modes is concerned... specifically parity... if you pass the parameter that way, it doesn't work. Anybody doing I/O to terminals in C may have noticed the disappearnce of the TT$M_ALTRPAR mask from a header file TTDEF.H. Everybody kludges; don't rag UNIX programmers porting code to VMS for not "VMS-i-fying" things... some things can't be "VMS-i-fied". You should be thankful that someone is willing to go through the pain. I would hazard a guess that greater than 50% of all DECUS stuff originated on non-VMS systems (This is an educated guess). | Terry Lambert UUCP: ...!decvax!utah-cs!century!terry | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |
terry@wsccs.UUCP (terry) (02/26/88)
In article <174@wsccs.UUCP>, dave@wsccs.UUCP (Dave E Martin "VAX Headroom") writes: > this file contains the definitions for terminals and (in my opinion) > is MUCH more understandable than the UNIX equivalent. Ha! Then why don't we see more termcap questions in comp.os.unix? We certainly see enough requests for TERMTABLE entries here... > users can also have their own private copies of the terminal database > if they want to define something and don't (or can't) put it in the > system termtable. But Dave, you still haven't (can't?) tell me how to get the !%^&*@!%@ SMG routines to tell me what the ******* F1 key is going to send to my read routine when someone hits it.... You are *intimately* familiar with why I can not wait for SMG$ to parse the bejesus out of my input. Eagerly awaiting a method of strangling the info out of SMG$... | Terry Lambert UUCP: ...!decvax!utah-cs!century!terry | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |
newbery@comp.vuw.ac.nz (Michael Newbery) (03/04/88)
In article <190@wsccs.UUCP> terry@wsccs.UUCP (terry) writes: >[...] You may also notice that ANSI terminals have 24 lines and **************************** Nonsense! Where in X3.64 does it say this? >[...] There is a terminal database on VMS. It's called >SYS$SYSTEM:SMGTERMS.TXT. Which insufficient software (especially DEC's) uses - which is the nub of the problem. The rest of your summary seems fair to me. -- Michael Newbery Internet: newbery@comp.vuw.ac.nz Une boule qui roule tue les poules. (Landslides kill chickens)
hildum@iris.ucdavis.edu (Eric Hildum) (03/04/88)
In article <191@wsccs.UUCP> terry@wsccs.UUCP (terry) writes: >I could ask it about the sequence to use >to clear the screen, etc, but *only* _OUTPUT_ oriented stuff. > Is this a reference to SMG$GET_TERM_DATA? I think that will do what you want. Or are you saying that you tried this routine, and only the output oriented information is returned? Also, I take it that you are working in C. What version? We will need a little more information to begin to answer your questions. > DEC makes mistakes (*BLASPHEMY!* Kill the infidel!)... for instance >look at the docs in the IO Services manual where the QIO$ for setting tty >modes is concerned... specifically parity... if you pass the parameter >that way, it doesn't work. Anybody doing I/O to terminals in C may have >noticed the disappearnce of the TT$M_ALTRPAR mask from a header file >TTDEF.H. > It seems you have found some things to SPR - have you? I have never said Digital was foolproof. The only way they will get better is if the comments, suggestions and criticisms are directed to them through the channels that they have set up to handle such things. And they do respond - just compare releases, and you will see that they do try to provide what people want. Eric dehildum@ucdavis.ucdavis.edu (Internet) dehildum@ucdavis.bitnet (BITNET) ucbvax!ucdavis!dehildum (uucp)
rrk@byuvax.bitnet (03/05/88)
I agree wholeheartedly... SMG is garbage for programming of serious applications. I tried for months to get SMG to do lots of those low level things and finally gave up and wrote my own screen handler with its own TERMTABLE type files (but much more sophisticated, flexible, and efficient) so that I could (among other things) read a whole slew of escape sequences in one QIO and then translate them, and it wouldn't hurt either logic or efficiency if my QIO happened to terminate in the middle of an escape sequence. It also allowed me to do lots of other things like perform some operation to the screen which modified the screen external to the screen handler and then tell the screen handler about this change on the PHYSICAL screen so that it could properly know what was there for the next update without having to invalidate and repaint what it didn't place there itself. Another function I had to have (and built into my own screen handler) was the ability to turn on hardware insert mode and tell the virtual screen that it was on so that people could insert text into the middle of a line without having to have the line repainted with every keystroke. I found no way to do this through SMG. Another thing that was very important, but lacking in SMG was the ability to imbed attribute and positioning strings into the text. If you store screens in files separate from the main program, there is no easy way to imbed codes giving control information to the screen such as cursor control or attribute changes like bolding certain words. I recognize that you can set the ALLOW ESCAPE flag and theoretically send VT100 control codes through, but SMG choked on lots of codes that a VT100 would have had no problem with, and the SMG documentation discourages use of this flag and there are many things that still can't be done in this way... SMG is also very inefficient in the control codes it sends out. It wastes lots of characters in many places. Other essential features missing in SMG include: A nice way to get SMG to batch things without the programmer having to call begin_update and end_update everywhere. The obvious solution here was to make updates occur only at user input or when specifically asked for (via a special code) or during forced delays. Something to cause update to be disabled even during periods of input if theuser gets ahead of the application, allowing the screen manager to skip unnecessary screens until the application or baud rate catches up with the user. The concept of a set of SMG routines for use by applications designed to be terminal independant is nice, but good design is a must. I hope SMG is scrapped or revamped in a major way in 5.0. Otherwise, it is a sad excuse for a screen handler, and without a real future.
terry@wsccs.UUCP (terry) (03/12/88)
In article <13328@comp.vuw.ac.nz>, newbery@comp.vuw.ac.nz (Michael Newbery) writes: > In article <190@wsccs.UUCP> I write: > >[...] You may also notice that ANSI terminals have 24 lines and > **************************** > Nonsense! Where in X3.64 does it say this? Find one ANSI 3.64 compliant terminal not: 1) Made by IBM (ah, yes, a maker of freindly terminals, indeed ;-) 2) Pretended to by an MesS-DOS box (UPort and SCO fall into here) 3) Built with connection to #2 in mind (things like the wy60 and wy75, wy85 don't count, in other words) And I'll reverse my statement. Till then, I think I'll let it stand. I think you took me rather out of context. I was simply pointing to an obvious difference between ANSI 3.64 and ANSI.SYS, as a generalization. After Re-reading the standard, I agree that it does not say this, but neither does it say that all characters are displayed right-side-up... this is, however, the most common, and therefore de-facto standard, method of implimentation. > >[...] There is a terminal database on VMS. It's called > >SYS$SYSTEM:SMGTERMS.TXT. > Which insufficient software (especially DEC's) uses - which is the nub > of the problem. Because it's poorly implimented and very sloooooooow. THAT is the nub of the problem. If you'll recall, I was simply contradicting someone who had said there wasn't one, not advocating it's use, any more than I advocate the use of MP/M for several secretaries doing word-processing. | Terry Lambert UUCP: ...!decvax!utah-cs!century!terry | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |
newbery@comp.vuw.ac.nz (Michael Newbery) (03/16/88)
In article <307@wsccs.UUCP> terry@wsccs.UUCP (terry) writes: >> >[...] You may also notice that ANSI terminals have 24 lines and >> **************************** >> Nonsense! Where in X3.64 does it say this? > > Find one ANSI 3.64 compliant terminal not: > > 1) Made by IBM (ah, yes, a maker of freindly terminals, indeed ;-) > 2) Pretended to by an MesS-DOS box (UPort and SCO fall into here) > 3) Built with connection to #2 in mind (things like the wy60 and > wy75, wy85 don't count, in other words) > > And I'll reverse my statement. Till then, I think I'll let it stand. * Visual 550 (34 lines) * Lots of terminal emulators on Macs, Amigas, DEC GPX workstations (not MS-DOS boxes :-) Granted, 80x24 is the de facto standard for terminals. DEC have sort of added 132x24. I still don't think this is a _good thing_. It pains me when I fire up the VT100 window on a *DEC* workstation, resize it to something other than 24*80/132 and watch all the DEC standard software break - and I don't mean just run as if they had a smaller screen! I mean fail to work at all! >I think you took me rather out of context. I was simply pointing to an [...] Sorry. I read your statement to be an assertion that ANSI terminals had to have 24 lines. I gather you meant that most 3.64 compliant terminals, like most terminals of any persuasion, have 24 lines. >> >[...] There is a terminal database on VMS. [...] >> which insufficient software (especially DEC's) uses - which is the nub >> of the problem. > > Because it's poorly implimented and very sloooooooow. THAT is the >nub of the problem. If more DEC software was forced to use it by the corparate thought police, it might magically become faster and less poorly implemented :-) -- Michael Newbery Internet: newbery@comp.vuw.ac.nz Une boule qui roule tue les poules. (Landslides kill chickens)
earleh@eleazar.Dartmouth.EDU (Earle R. Horton) (03/23/88)
In article <307@wsccs.UUCP>, terry@wsccs.UUCP (terry) writes: > In article <13328@comp.vuw.ac.nz>, newbery@comp.vuw.ac.nz (Michael Newbery) writes: > > In article <190@wsccs.UUCP> I write: > > >[...] You may also notice that ANSI terminals have 24 lines and > > **************************** > > Nonsense! Where in X3.64 does it say this? > > Find one ANSI 3.64 compliant terminal not: > > 1) Made by IBM (ah, yes, a maker of friendly terminals, indeed ;-) > 2) Pretended to by an MesS-DOS box (UPort and SCO fall into here) > 3) Built with connection to #2 in mind (things like the wy60 and > wy75, wy85 don't count, in other words) > > And I'll reverse my statement. How about a Tek4105 (30 lines), or VersaTerm PRO on a Mac II (36 lines with Apple Monitor), or Ann Arbor Ambassador terminals (18 to 60 lines), the xterm program under X-Windows (depends on monitor, but I have used it with 55 lines, 110 columns). There's lots of ANSI terminals, and even VT100 look-alikes, and emulators which can display more or less than 24 lines. On the Tektronix, you can press the Setup key, and type: * CODE ANSI * DALINES 4 Then you get an ANSI 3.64 compatible terminal with a 4-line text area! (Remember to "SET TERM/PAGE=4" afterwards and before running your favorite VMS editor.) EDT doesn't seem to like the big ANSI terminals, even after doing "SET TERM" to set the size, but TPU doesn't seem to mind them one bit. DEC is actually not too bad in this area, since they do allow you to change the display size. ^^^^^^^^^^^^ You may reverse your statement now. -- ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************