Pseudo-terminal to virtual-terminal mapping

[Jonathan Cronin]

What's the simplest way to determine the virtual terminal corresponding to a pseudo-terminal. I.E given a FT unit number or an FT open on a channel, whats the simplest way to determine the VT device name or unit number?

I assume/hope there's a GETDVI constant for this, but I haven't been able to find it. I'd rather not scan all the VT devices and test the TT_PHYDEVNAMs for the FT device.

Jonathan

[Hoff · Accepted solution]

FT devices do not necessarily have associated virtual terminal VT devices.

Some specifics on the devices would be useful, as would some information on the particular application requirements and application background, too.

Beyond $getdvi items TT_ACCPORNAM and such, the usual approach can involve some kernel-rummaging or potentially some $device_scan matching operations.

And if scanning the device database is too difficult or expensive, then that ties back to the application requirements; to the frequency of scans required, or the numbers of devices or such. If that's the case, then there might be a way you can cache that details, or find an alternative approach; that gets back to some background on the requirements.

For one application sequence that's fairly similar (and around IP sockets and BG devices), see:

http://groups.google.com/group/comp.os.vms/browse_thread/thread/ec43c38d956b7fba

[Jonathan Cronin]

| FT devices do not necessarily have associated virtual terminal VT devices.

Really? I've only just started using them, and I seem to get one without asking...

| Some specifics on the devices would be useful, as would some information on the particular application requirements and application background, too.

See bottom.

| Beyond $getdvi items TT_ACCPORNAM and such, the usual approach can involve some kernel-rummaging or potentially some $device_scan matching operations.

| And if scanning the device database is too difficult or expensive, then that ties back to the application requirements; to the frequency of scans required, or the numbers of devices or such. If that's the case, then there might be a way you can cache that details, or find an alternative approach; that gets back to some background on the requirements.

I'm OK with doing the scan, as far as performance goes, I just didn't want to write the code if I was just missing something in the docs.


| For one application sequence that's fairly similar (and around IP sockets and BG devices), see:

|http://groups.google.com/group/comp.os.vms/browse_thread/thread/ec43c38d956b7fba

This seems to cover the reverse case, which does work: Given a VTAxx, get$dvi( TT_PHYDEVNAM ) returns the FT device. I want to do the reverse.

To make a short story long, we have a customer system that has to transfer files to an external system. The external entity has specified sftp with passwords. While we try to get this changed to SCP and public keys, I am cobbling up something in case the change is turned down.

Long ago we wrote a pseudo-keyboard library based on mailboxes; create three mbxes, for input, output, and termination and pass those to $CREPRC. On top of that we wrote a callable FTP library (this was before there was a callable FTP implementation available.)

I wrote an SFTP version of the FTP library (not pretty), but passwords didn't work. There was a suggestion in a thread on this forum (from you, I think?) that the pseudo-terminal device might work. So off I went. My plan is to open the FT, get the corresponding VT and pass that to CREPRC as the input and output. (I am trying to avoid having to use a password to login; one security flaw is better than two.)

So my wider question is how do I get a pseudo-terminal connected to DCL without explicit login?

Thanks for your help,

Jonathan

[Hoff]

I'd spend the time pounding on the target folks to get the keys working; that's the most expeditious approach. That's really fast, and a whole lot less effort.

http://labs.hoffmanlabs.com/node/1118

Direct password input from within a batch process is (AFAIK) prohibited by most ssh clients. Reasonably so, too.

This (reasonable and security-minded) prohibition against embedded passwords is what the FT device stuff and particularly the pseudo-terminal interface (I/O User's Reference Manual, ptd$ routines) tries to hack around.

AFAIK, you don't need to look at the VT stuff here. You create the FT device, connect the new DCL process to it via SYS$INPUT and SYS$OUTPUT, and then start slamming I/O at the FT via the OpenVMS ptd$ pseudo-terminal device calls.

The other option is to punt this stuff and use a Unix, Mac OS X or Linux box and a shell command such as expect. The expect tool is way beyond what's available with OpenVMS here, so you could stick one of these boxes on the LAN as a hack and an intermediate in the connection, and be (more or less) done with this stuff pending the creation of the keys.

For code examples of using the ptd$ stuff, see sys$examples:alpha_logger.c and some stuff on the OpenVMS Freeware including hglogin.

As for other libraries that might interest you, see the cURL library:

http://labs.hoffmanlabs.com/node/1330

There is a port to OpenVMS, though the OpenVMS port has (and has still?) omitted the sftp pieces in the OpenVMS port.

[Jonathan Cronin]

| I'd spend the time pounding on the target folks to get the keys working; that's the most expeditious approach. That's really fast, and a whole lot less effort.

True, this is as much an excuse to poke around PTD$*

http://labs.hoffmanlabs.com/node/1118

| Direct password input from within a batch process is (AFAIK) prohibited by most ssh clients. Reasonably so, too.

| This (reasonable and security-minded) prohibition against embedded passwords is what the FT device stuff and particularly the pseudo-terminal interface (I/O User's Reference Manual, ptd$ routines) tries to hack around.

| AFAIK, you don't need to look at the VT stuff here. You create the FT device, connect the new DCL process to it via SYS$INPUT and SYS$OUTPUT, and then start slamming I/O at the FT via the OpenVMS ptd$ pseudo-terminal device calls.

OK, I'll try that. (Hmm, just got my head around it; using QIO instead of PTD$ gets you the controlled side...)

| The other option is to punt this stuff and use a Unix, Mac OS X or Linux box and a shell command such as expect. The expect tool is way beyond what's available with OpenVMS here, so you could stick one of these boxes on the LAN as a hack and an intermediate in the connection, and be (more or less) done with this stuff pending the creation of the keys.

Yeah, we've got a UNIX fe (Solaris actually) for similiar issues...

| For code examples of using the ptd$ stuff, see sys$examples:alpha_logger.c and some stuff on the OpenVMS Freeware including hglogin.

| As for other libraries that might interest you, see the cURL library:

| http://labs.hoffmanlabs.com/node/1330

| There is a port to OpenVMS, though the OpenVMS port has (and has still?) omitted the sftp pieces in the OpenVMS port.

Actually, this was my original proposal if we had to do SFTP (I found it at your site :) ), until I found the sftp was (still) missing.

Thanks for all your help, I'm closing the thread.

[John Gillings]

Jonathan,

I'm not sure I understand why you need to map FT to VT. Remember every VT is either detached or connected to a physical terminal (even if it's a pseudo-physical terminal), but not every physical terminal needs to be connected to a virtual terminal. Since the physical terminal has no idea it's talking to a VT, there's no simple way to determine the mapping in that direction.

I've attached some very old, very klunky code (compile with /standard=VAXC) which implements a software "wire" using pseudo terminals. I wrote it to satisfy a program which expected to see a "real" serial port, but I wanted it to connect to a telnet session. Sounds similar to what you're doing.


I've added null stubs for the logging routines. Note I haven't compiled or run this program for a very long time, so I have no idea if something post V7.something has broken it. At least it should give you some idea of using the PTD routines. Here are comments I sent to someone else (somewhat out of context here, but hopefully you'll get the idea:

As written, this program it intended to be run in a subprocess. It creates a terminal device (and associated logical name - first parameter), and a subprocess. Note that from experiments, it seems *necessary* to provide a login procedure of some sort. So, for example, if you had a file called "LOGIN.COM" containing only the line "$ EXIT", you could create a "wire" with:

$SPAWN/NOWAIT MCR dev:[dir]WIRE WW "@dev:[dir]LOGIN.COM"
%DCL-S-SPAWNED, process GILLINGS_1 spawned
$

******** Wire *******

logical name .........: WW
spawn command.........: @USER$TSC:[GILLINGS.WIRE]login.com
local FTA device .......: _FTA30:
remote FTA device ......: _FTA31:

$
$
$ show log ww
"WW" = "_FTA30:" (LNM$JOB_80EBFE00)
$ set host/dte ww

%REM-I-TOQUIT, connection established

Press Ctrl/\ to quit, Ctrl/@ for command mode


$ ! NOW CONNECTED TO THE "WIRE" SUBPROCESS
$
$
$
$
$ show proc

21-JUN-2000 13:48:46.54 User: GILLINGS Process ID: 2020025C
Node: XARA Process name: "GILLINGS_2"

Terminal:
User Identifier: [USERS,GILLINGS]
Base priority: 4
Default file spec: USER$TSC:[GILLINGS.WIRE]
Number of Kthreads: 1

Devices allocated: XARA$FTA31:
$ logo

%REM-E-PORTRXERR, port receive error
-SYSTEM-F-HANGUP, data set hang-up

%REM-S-END, control returned to node XARA
%SYSTEM-F-DEVOFFLINE, device is not in configuration or not available
$ ! BACK TO MAIN PROCESS


So how does this help you? Well, you MIGHT be able to connect your SYS$INPUT/SYS$OUTPUT mechanism to the local FTA device and find that it just works, once you've TELNETed to the remote system in the wire subprocess. Though it's a fairly expensive proposition having TWO additional processes to shunt characters around. A cleaner and tidier option might be to break the program in two and incorporate the outward bound half of this program into your own program. You would still need ONE additional process, but you were going to anyway.

Note about the program, it needs to be compiled /STANDARD=VAX (and even then you get an informational message) and has a small FORTRAN I/O package to perform logging - I hate the C I/O model, sorry. Easy to rip out the logging part, but you may be able to use it for debugging.

[Jonathan Cronin]

My original problem was solved, just by passing the FT device directly to $CREPRC as SYS$INPUT/SYS$OUTPUT, as Hoff and John suggested. So there is no need to worry about the VT at all.

I was misled by my initial experimentation, before using $CREPRC, when "poking" the FT caused it to offer a login prompt, and the resulting process had a VT as the TT:.

(And I was influenced by my youthful upbringing on RSTS, where each PK device had a corresponding hardwired KB device, so I expected it to work this way :) )

Thanks again, Jonathan