Hmm, there seems to be some issues with our network in general.. I'll se
what I can do.
On Fri, Jun 11, 2010 at 11:31:40PM +0100, Sampsa Laine wrote:
Is MIM down? I can't see it (or PONDUS)..
Sampsa
On Thu, 2010-06-10 at 19:29 -0600, Johnny Billquist wrote:
It might be that someone have already done so. It might be worth
searching through old DECUS libraries...
... and that's always fun!
The irony of history.
LAT and DECservers were invented so that machines no longer would need to have local ports.
Now you are using LAT and DECservers to access machine local ports. :-)
Yes. I know what you mean, and what you want to do. However, DEC did definitely not envisage that. Their intention was the exact opposite.
All that said, it is mostly doable under VMS, but it requires that you write some software yourself.
It might be that someone have already done so. It might be worth searching through old DECUS libraries...
Johnny
Sampsa Laine wrote:
No I see how my way of doing it might seem backwards, I mean why share a modem from a host machine when terminal servers were invented for doing it?
Doesn't mean it wouldn't be a nice feature to have :)
Sampsa
On 11 Jun 2010, at 01:36, Johnny Billquist wrote:
What pays to remember is that once you had LAT and DECservers, you didn't use serial ports on your VAX anymore, especially not on a site where you had several VAXen. You *obviously* had DECservers if you were using LAT, and you *obviously* wanted to put the modem on the DECserver if you had one, and *especially* if you wanted to access the modem from several machines.
So yes, it's an obvious idea, and it had an obvious answer. It's just you who are trying to do things backwards... :-)
Johnny
No I see how my way of doing it might seem backwards, I mean why share a modem from a host machine when terminal servers were invented for doing it?
Doesn't mean it wouldn't be a nice feature to have :)
Sampsa
On 11 Jun 2010, at 01:36, Johnny Billquist wrote:
What pays to remember is that once you had LAT and DECservers, you didn't use serial ports on your VAX anymore, especially not on a site where you had several VAXen. You *obviously* had DECservers if you were using LAT, and you *obviously* wanted to put the modem on the DECserver if you had one, and *especially* if you wanted to access the modem from several machines.
So yes, it's an obvious idea, and it had an obvious answer. It's just you who are trying to do things backwards... :-)
Johnny
Sampsa Laine wrote:
On 9 Jun 2010, at 01:27, Gregg Levine wrote:
Hello!
I see.
A good question. Now that I know that it is someone physical where you
are, I am fresh out of ideas.
This MUST be doable, it's such an obvious idea :)
Let's say back in the day I had a modem connected to one of my VMS boxes, would not sharing it over LAT be pretty obvious?
What pays to remember is that once you had LAT and DECservers, you didn't use serial ports on your VAX anymore, especially not on a site where you had several VAXen. You *obviously* had DECservers if you were using LAT, and you *obviously* wanted to put the modem on the DECserver if you had one, and *especially* if you wanted to access the modem from several machines.
So yes, it's an obvious idea, and it had an obvious answer. It's just you who are trying to do things backwards... :-)
Johnny
Sampsa Laine wrote:
Guys,
I want to create a LAT service connected to a virtual terminal port (created using TELNET/CREATE) and then when users connect to this service they get redirected over telnet to the destination.
This is what I tried:
lcp:==$sys$system:latcp
TELNET/CREATE B4BBS 23 1
lcp create port lta1337/application
lcp set port lta1337/port=tna1
lcp create service b4bbs
lcp set port lta1337: /service=b4bbs
However when I connect to the service b4bbs I am not redirected to the TNA1 telnet connection, but just get the normal log in screen of the host I created the service on.
Where am I going wrong here?
I've done some commenting on this before, but as I'm running through my backlog I figured I might as well answer this again.
lcp set port lta1337: /service=b4bbs
will not cause service b4bbs to connect to port lta1337:, but if you run a terminal emulation program on the VMS machine, and connect to lta1337:, you will in fact be connected to the b4bbs service.
lcp set port lta1337/port=tna1
is an incomplete setup for doing a similar thing.
Both are for configuring reverse lat setups.
When you create a reverse lat setup, you create a local terminal (in this case lta1337:). When someone on the VMS box opens this device, they will be connected to whatever you have setup this port to talk to.
There are two different ways of going about the setting up. You can:
1) Specify a specific server and port
2) Specify a LAT service
Your first "attempt" specifies only the port, but not the server. Thus, if someone would have tried to connect after that had been specified, the connection would fail, since no server had been specified and thus the reverse LAT wouldn't have an idea on where to actually connect to.
However, your second specification makes that void anyway, since you instead specify a service that should be connected to.
In addition to all this, you also create a service called b4bbs, which is something others can connect to, and when they do, LOGINOUT will start on that port, to make it possible for the user to log in. Notice that there is no real, obvious correspondance between your lta1337: setup, and the b4bbs service, apart from the fact that if someone were to connect to lta1337:, they should be connected as with a loopback to the same machine, and presented a login session (assuming that the ethernet packets gets properly looped here, which I'm a bit unsure about).
Johnny
Not possible out of the box, as far as I know.
There are several pieces needed to understand to make this work.
You need a way to connect one serial port to another serial port. In this case, the "incoming" serial port should be connected to a physical serial port on the machine. Once again, not something supported out of the box, but this would just require a small program to be written. Not that difficult.
Important to know and understand is that you are not, in fact, providing any reverse LAT service. What you want is that an incoming LAT connection should not in fact start LOGINOUT, but instead allow you to communicate on a physical serial port on the VMS box.
So, on the VMS box, a program needs to be running, which are in control of the "serial" ports on which LAT will connect. And once a connection is noticed, it should just pass data back and forth between that port and the physical port you want to connect to.
One additional problem here is that you would really like to create two different LAT services on the VMS box for this to work, since I would assume you would still also be interested in logging in normally with LAT on the system.
As far as I know, this is not possible.
Reverse LAT, on the other hand, is a way on a VMS box (or any other system as well), to specify that a specific destination should be connected to when you open a specific port on the local machine. Thereby implicitly making an outgoing LAT connection from the VMS box.
This was/is typically used for such services as modems or serial port printers. Open TT47: on your system, and output to it. And the output will appear on a currently free printer, as an example.
That works the same on Unix systems as well.
The lat implementation for Linux is very buggy by the way. I've been using it extensively the last few weeks to make a reverse connection using llogin to a DECserver, and it occasionally hangs so bad I need to totally restart it to wake it up. So while it might have some useful features, it's unfortunately not in a good shape. I remember looking at it many years ago because of some other problems I had back then, and decided that it was not worth trying to figure out the code. I should write my own implementation instead, especially since the LAT specs are available. However, as usual, I have not had time to do so... :-(
Johnny
Sampsa Laine wrote:
OK,
I see - so there's no way of doing this on VMS then? Good thing the Linux LAT seems to do the trick though.
Sampsa
On 9 Jun 2010, at 07:48, Johnny Billquist wrote:
Sampsa Laine wrote:
On 9 Jun 2010, at 01:27, Gregg Levine wrote:
Hello!
I see.
A good question. Now that I know that it is someone physical where you
are, I am fresh out of ideas.
This MUST be doable, it's such an obvious idea :)
Let's say back in the day I had a modem connected to one of my VMS boxes, would not sharing it over LAT be pretty obvious?
Yes. And they way you did it was by having a DECserver, on which the modem was connected.
Johnny
OK,
I see - so there's no way of doing this on VMS then? Good thing the Linux LAT seems to do the trick though.
Sampsa
On 9 Jun 2010, at 07:48, Johnny Billquist wrote:
Sampsa Laine wrote:
On 9 Jun 2010, at 01:27, Gregg Levine wrote:
Hello!
I see.
A good question. Now that I know that it is someone physical where you
are, I am fresh out of ideas.
This MUST be doable, it's such an obvious idea :)
Let's say back in the day I had a modem connected to one of my VMS boxes, would not sharing it over LAT be pretty obvious?
Yes. And they way you did it was by having a DECserver, on which the modem was connected.
Johnny
On Mon, 07 Jun 2010 09:55:36 +0200, you wrote:
3. Oh well, it would be nice to learn where is the culprit and how to
rebuild a TOPS-10 monitor from scratch! :-) Now I've posted a request to
alt.sys.pdp10. Let's see if someone will explain me what to do.
Hello again!
As I wrote, I posted a plea for help in alt.sys.pdp10 and obtained some very
useful answers. They explained me how to patch the monitor binary file and
now the CPU hosting the KLH10 emulator is only 0.5% busy when TOPS-10 idles.
It's a very easy task and takes less than a minute to complete. If someone
is interested I can describe it here, or can go read the thread on the NG.
Back in topic, now I'll head on to a complete DECnet-10 setup (in my scarce
spare time). :-) Do there is someone here that has suggestions on this?
Bye,
G.
