Getting Terminal "Device Attributes"

[Jack Trachtman]

From within a DCL script (basically LOGIN.COM)I need to be able get the VT "Device Attributes" so that I can differentiate between the different Terminal Emulator products we use.

I can issue the cmd from DCL ([>c), but can't capture the return string, probably because the return string doesn't end with a line terminator character. (My search of the forums hasn't provided any ideas.)

1) Is there any way to do this witin DCL?

2) If not within DCL, can it be done with any of the other scripting languages available (eg PERL, Python, etc.)

3) (My last choice, since I haven't used assembler in many years) Is there an example pgm in assembler w/source code that I could modify?

4) Any other ideas?

TIA

[Craig A Berry]

There are lots of things you can get from F$GETDVI in DCL or equivalent in other languages. What characteristics in particular do you want?

Here are some examples. Try HELP LEXICAL F$GETDVI for more options.

$ write sys$output f$getdvi("tt:","device_type_name")
VT400 Series
$ write sys$output f$getdvi("tt:","tt_deccrt")
TRUE
$ write sys$output f$getdvi("tt:","tt_deccrt4")
TRUE
$ write sys$output f$getdvi("tt:","tt_editing")
TRUE
$ write sys$output f$getdvi("tt:","tt_ansicrt")
TRUE
$ write sys$output f$getdvi("tt:","tt_regis")
FALSE
$ write sys$output f$getdvi("tt:","tt_app_keypad")
FALSE

[Hein van den Heuvel · Accepted solution]

Yeah Craig, but all those report are from what the terminal is 'claimed' to be.
Now that claim may have come from a SET TERM/INQ and VMS may have figured it out, or it may have just been hardcoded.

I believe Jack wants to read the report fromteh terminal. I'd liek to think I invented how to do so in DCL many years ago, but can not find an early 'proof' now.
I could find several examples.

The trick is that the response comes as an escape sequence, which normally is a terminator and available in the data read.
But if you cleverly juggle SET TERM/ESCAPE, then you can make it come out:

$esc = "$"
$esc[0,8] = 27 ! or use.. $csi[0,8] = 155
$set term/noecho/noesc
$write sys$output esc,"[c",esc,"[c" !Ask identification TWICE.
$read/prompt="" sys$command escape !terminate with escape part of report
$set term/esc !Allow escape sequences as terminators
$read/prompt="" sys$command id !Read body of escape sequence terminated
$! by escape sequence from identification
$set term/echo !Reset terminal.
$write sys$output id


Here is a seemingly complete example.
Serach comp.os.vms for "noesc vaxman"

http://groups.google.com/group/comp.os.vms/search?hl=en&group=comp.os.vms&q=%2Fnoesc+vaxman

Hth,
Hein.

[Hein van den Heuvel]

Oops, sorry 'bout the sloppy typing.

I did find a relatively early copy::

--------------------------------------------------------------------------------
Note 116.10 Screen dimensions from DCL? 10 of 10
STAR::VANDENHEUVEL "You have 1 new message" 18 lines 22-AUG-1991 19:23
-< I always though this to be a neat dcl hack >-
---------------------------------------------------------------------------------
The following procedure read a cursor posion report from a terminal
using 'pure' dcl. Do NOT expect too much in the area of cursor
position reading because DCL prompts tends interfere too much.

Have fun,
Hein,


$csi[0,8] = 155
$set term/noecho/noesc
$write sys$output csi,"6n",csi,"5n" !Ask cursor report & identification
$read/prompt="" sys$command escape !terminate with escape part of report
$set term/esc !Allow escape sequences as terminators
$read/prompt="" sys$command cursor !Read body of escape sequence terminated

$! by escape sequence from identification
$set term/echo !Reset terminal.
$write sys$output cursor

[Hoff]

What might you be up to here? (I well understand the immediate problem and plan, but am not quite as comfortable with the background and the problem itself.)

OpenVMS has traditionally gone out of its way to try to avoid this sort of distinction; with SMG and the core libraries, the intent has always been to avoid having higher-level software to know details of lower-level code.

There are test suites available that can be brought to bear; there's a good one over at vt100.net, for instance.

Potential alternatives here include the answerback buffer, or standardizing the emulator(s) in use to those that function appropriately.

And I'd seek to avoid the whole problem, and use perl or php in an Apache CGI environment.

Assembler? Yeah, I can program that. There are no compilers here, and you're not comfortable with Bliss or other such (free) compilers?

There are any number of examples of sending $qio calls at the device, though I'd tend to look to use the SMG calls whenever I can. Use of SMG here, whether identifying the device, or retrieving the control sequences appropriate for the particular terminal.

The $qio calls stuff I can point to that deals with this sort of thing is in the Freeware (including the Hoffman_Examples and srh_examples directories on the Freeware distros); that's mostly in C, however. (Not so much SMG, but there are examples of that available around, too.)

But again, what are you up to?

Stephen Hoffman
HoffmanLabs LLC

[Jack Trachtman]

Hein,

Thanks! That script gives me exactly what I need.

Since your answer, I've reread the I/O manual on the terminal driver, but still, I would have never have figured out the solution you came up with!

Hoff,

Thanks for replying.

To (try to) make a long story short: we have an old 3rd party app which is accessed by one of 2 different terminal emulators (employee gets to pick). We are installing the vendors new GUI front-end, which uses a built in TE to access the old app & get info via screen scraping. We need LOGIN.COM to figure out if the connection is from the new TE & if so, just get out of the way, otherwise present a menu. The vendor suggested using the terminal Secondary Dev Attributes to differentiate incoming TEs, & with the code Hein provided, I've shown that that will work (Note: the embedded TE does not have an Answerback option. We investigate that & other ideas).