- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Reverse Telnet TNA Device
Operating System - OpenVMS
1755422
Members
2835
Online
108832
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
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
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- 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
тАО02-18-2009 07:44 AM
тАО02-18-2009 07:44 AM
Re: Reverse Telnet TNA Device
We had to set TNA devices up for direct printing applications when a customer running old code switched from dedicated lines to internet VPN tunnels for their remote locations. No more LAT. Their MUXservers were replaced with DECserver 90M+ units, which use (2000 + physical port number) for the IP port. A printer on port 8 can be connected to using the DECserver IP address, port 2008.
We had to set a couple of additional settings on the ports; you might need to take a look at these if you have communications issues with your modem:
Local> CHANGE PORT 8 TELNET SERVER NEWLINE TO HOST
Local> CHANGE PORT 8 TELNET SERVER TRANSMIT CHARACTER SIZE 8
Local> CHANGE PORT 8 TELNET SERVER RECEIVE CHARACTER SIZE 8
The old applications used direct (non-queued, non-spooled) printing to the 'print device' for critical items, once a TXA serial port, later LTA, and now TNA.
I don't know how closely our experience will map to a modem connection.
TNA devices cannot be spooled, at least in the VMS versions involved. We kept the LTA device and spooled it to the new queue.
The create command looks like this:
TELNET/CREATE/TIMEOUT=0-0:0:10 192.168.178.2 2008 100
which creates device TNA100. We do SET TERM on the device to set page size/width/etc just like a normal physical port. For our queues we use PRTSMB as the processor; LATSYM kept causing spurious data when it disconnected.
We had to set a couple of additional settings on the ports; you might need to take a look at these if you have communications issues with your modem:
Local> CHANGE PORT 8 TELNET SERVER NEWLINE TO HOST
Local> CHANGE PORT 8 TELNET SERVER TRANSMIT CHARACTER SIZE 8
Local> CHANGE PORT 8 TELNET SERVER RECEIVE CHARACTER SIZE 8
The old applications used direct (non-queued, non-spooled) printing to the 'print device' for critical items, once a TXA serial port, later LTA, and now TNA.
I don't know how closely our experience will map to a modem connection.
TNA devices cannot be spooled, at least in the VMS versions involved. We kept the LTA device and spooled it to the new queue.
The create command looks like this:
TELNET/CREATE/TIMEOUT=0-0:0:10 192.168.178.2 2008 100
which creates device TNA100. We do SET TERM on the device to set page size/width/etc just like a normal physical port. For our queues we use PRTSMB as the processor; LATSYM kept causing spurious data when it disconnected.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-18-2009 12:30 PM
тАО02-18-2009 12:30 PM
Re: Reverse Telnet TNA Device
TELNET/CREATE_SESSION and TELNETSYM are great for changing from LAT to Telnet for printers that's what they're for. But they don't work properly for communications from the device back to the program.
In this case we're dealing with a modem which typically requires feedback from the device, so may not be workable.
In this case we're dealing with a modem which typically requires feedback from the device, so may not be workable.
A crucible of informative mistakes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-19-2009 04:58 PM
тАО02-19-2009 04:58 PM
Re: Reverse Telnet TNA Device
Some details of the application sequence might be useful; is the widget connecting to a known and fixed LT and lobbing out a dial sequence?
Or is the application going through the LAT $qio interface?
If it's the former, that might be feasible to deal with.
The latter would be a bit more work, as the $qio stuff is going to be different.
Depending on the particular goals and how this whole application is stacked, I might look to use a pseudo terminal. But I'm not sure that's appropriate without a few more words around the environment.
I can think of a massively brute-force and hideously ugly way to do this (if the application does use LAT $qio operations), but that's fodder for another discussion and a discussion only if it becomes necessary.
And depending on what the application does and what use rights exist here, it might be feasible to reverse engineer and/or recode it and/or disassemble it.
Or is the application going through the LAT $qio interface?
If it's the former, that might be feasible to deal with.
The latter would be a bit more work, as the $qio stuff is going to be different.
Depending on the particular goals and how this whole application is stacked, I might look to use a pseudo terminal. But I'm not sure that's appropriate without a few more words around the environment.
I can think of a massively brute-force and hideously ugly way to do this (if the application does use LAT $qio operations), but that's fodder for another discussion and a discussion only if it becomes necessary.
And depending on what the application does and what use rights exist here, it might be feasible to reverse engineer and/or recode it and/or disassemble it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-20-2009 03:59 AM
тАО02-20-2009 03:59 AM
Re: Reverse Telnet TNA Device
OK, we decided to place an Alpha Ds-10 into the configuration and let the old legacy prgram remian on an Alpha while the rest of the applications are on Itanium... As the code base for this app is 30 years old (litterally) it was more expedient to do this and get a committment to recode it using QIO... Having said that the response and deopth of thinking was just GREAT and no doubt someone hooking up printers will benefit greatly
- « Previous
-
- 1
- 2
- Next »
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP