- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Pseudo-terminal to virtual-terminal mapping
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2009 08:04 AM
тАО07-06-2009 08:04 AM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2009 09:04 AM
тАО07-06-2009 09:04 AM
SolutionSome 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2009 11:55 AM
тАО07-06-2009 11:55 AM
Re: Pseudo-terminal to virtual-terminal mapping
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2009 12:58 PM
тАО07-06-2009 12:58 PM
Re: Pseudo-terminal to virtual-terminal mapping
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2009 01:42 PM
тАО07-06-2009 01:42 PM
Re: Pseudo-terminal to virtual-terminal mapping
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-06-2009 02:07 PM
тАО07-06-2009 02:07 PM
Re: Pseudo-terminal to virtual-terminal mapping
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-07-2009 02:46 PM
тАО07-07-2009 02:46 PM
Re: Pseudo-terminal to virtual-terminal mapping
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