Thanks, will do that next time :)
I manually typed in enough licenses to get DECNET going and pasted in the file via CTERM :)
Sampsa
On 20 Aug 2012, at 14:54, hvlems at zonnet.nl wrote:
The license utiility can build com files for you:
$ license/issue/proc/out=imf.com *
Omit the /procedure qualifier and all you get is the data as printed on the PAK.
The license utiility can build com files for you:
$ license/issue/proc/out=imf.com *
Omit the /procedure qualifier and all you get is the data as printed on the PAK.
So I'm trying to load some licenses onto CHIMPY and am about to throw the box out of the window.
Basically, I burnt the licenses as .COM files onto a CDROM, and mounted them on the VMS box as follows:
MOUNT DQB1: /MEDIA=CDROM/OVER=ID/UNDEF=(STREAM_LF:132)
When I try to run the COM file, I get loads of weird DCL errors, it's clearly not parsing the file right.
This should not be this difficult.
sampsa
On 08/16/2012 10:18 PM, Gregg Levine wrote:
So where are we with this package? I thought I'd write now and ask
rather then wait longer... Incidentally I've stuck a spare laptop in
place of the Compaq portable that was posing as the console for the
Sparc system. It's strange, I also attached the monitor that will be
connected to the Sparc to the laptop's monitor/projector port, and it
came up on the monitor instead of on the laptop screen first.
And the keyboard to the port for the keyboard and mouse on the laptop.
I've been in crunch mode, just getting caught up on a bunch of
long-neglected stuff around here. I'll get to it soon but not for a few
more days at least.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Fri, Aug 10, 2012 at 12:17 AM, Dave McGuire <mcguire at neurotica.com> wrote:
On 08/09/2012 11:55 PM, Gregg Levine wrote:
Maybe I need to ship you a care package. Send me your address.
Hello!
Okay coming at via separate travel, actually private message.
Sounds good.
Thanks! One of these days I need to visit your space.....
You're always welcome!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Hello!
So where are we with this package? I thought I'd write now and ask
rather then wait longer... Incidentally I've stuck a spare laptop in
place of the Compaq portable that was posing as the console for the
Sparc system. It's strange, I also attached the monitor that will be
connected to the Sparc to the laptop's monitor/projector port, and it
came up on the monitor instead of on the laptop screen first.
And the keyboard to the port for the keyboard and mouse on the laptop.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 2012-08-15 14:53, Paul_Koning at Dell.com wrote:
On Aug 15, 2012, at 5:05 AM, Johnny Billquist wrote:
On 2012-08-15 10:57, Sampsa Laine wrote:
Yes, I was aware of the batch submission, but wanted to do it the "ssh way" for a particular reason..
Ok. Note, however, that the solution you came up with now is not really generally usable in DECnet, but is rather VMS-specific. But on the other hand, more or less any solution will be rather specific...
The details are, but the general mechanism is common. See the Session Control layer specification. Basically, server application addresses come in two forms (three, maybe, but the third doesn't really make sense) -- a name, or a number. For example, FAL is number 17.
Right.
This is a named task object. The basic idea carries across, but for RSX, for instance, the named object must be an installed task name, and is not a file name.
That part is standardized, and the object numbers are registered (though no names are). What isn't standard is how those session control requests are mapped to operating system objects or actions.
Yes. Which is why I made my comments that not only was Sampsas solution VMS-specific, but any solution will be rather specific...
For example, in RSTS (DECnet/E), incoming connections can go to already running programs that have registered the object name and/or number. If there isn't one, the request is looked up in a database set by NCP which defines the mapping from name or number to a program. Unlike VMS, there is no default rule that a name maps to that same string as an executable file. But what Sampsa did could be done to a RSTS node so long as there is a session control database entry that maps that task name to the script file as the thing to execute.
In RSX, you have a database for numbered objects to specific task names. Object 0 is special, just like in VMS, in that you then give a name, and that name is outside the scope of DECnet. For RSX, the name is searched in the installed task list of the OS, while for VMS, it is assumed to be a filename in a specific directory.
For both numbered and named objects, the task does not have to be running in RSX. DECnet will activate the task if it isn't running. But it must be a task known to the system, or else it fails. And you have a database of mappings for numbered objects to which task to run.
Johnny
On Aug 15, 2012, at 5:05 AM, Johnny Billquist wrote:
On 2012-08-15 10:57, Sampsa Laine wrote:
Yes, I was aware of the batch submission, but wanted to do it the "ssh way" for a particular reason..
Ok. Note, however, that the solution you came up with now is not really generally usable in DECnet, but is rather VMS-specific. But on the other hand, more or less any solution will be rather specific...
The details are, but the general mechanism is common. See the Session Control layer specification. Basically, server application addresses come in two forms (three, maybe, but the third doesn't really make sense) -- a name, or a number. For example, FAL is number 17.
That part is standardized, and the object numbers are registered (though no names are). What isn't standard is how those session control requests are mapped to operating system objects or actions.
For example, in RSTS (DECnet/E), incoming connections can go to already running programs that have registered the object name and/or number. If there isn't one, the request is looked up in a database set by NCP which defines the mapping from name or number to a program. Unlike VMS, there is no default rule that a name maps to that same string as an executable file. But what Sampsa did could be done to a RSTS node so long as there is a session control database entry that maps that task name to the script file as the thing to execute.
paul
TELL.COM seems simpler :)
Sampsa
On 15 Aug 2012, at 15:01, Steve Davidson wrote:
Sampsa,
For VMS specific you can us SYSMAN. It does NOT require a cluster. It
does require that you specify the username and password of the remote
however.
$ MCR SYSMAN
SYSMAN> set environment/node=<nodename>/user=<username>
Remote Password: <remote accounts password>
SYSMAN> do @foo.com
SYSMAN>
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Sampsa Laine
Sent: Wednesday, August 15, 2012 05:20
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] 'rexec' or 'ssh <command>' over DECNET
Well, the logs are transferred over DECNET to the main host
that runs SSH (the others are too slow to run SSH).
But they are generated by a DCL script on the node from which
they are extracted (basically, DCL scripts are run on KUHAVX
and LABVAX which copy the exported logs to SOLAR5).
So I execute the log generation process (which tells KUHAVX +
LABVAX to export their logs to SOLAR5) and then fetch them
from SOLAR5.
Sampsa
On 15 Aug 2012, at 12:15, Johnny Billquist wrote:
On 2012-08-15 11:09, Sampsa Laine wrote:
I am aware of this - I am using this to pull some logs
from a couple of boxes to another, all VMS.
Eh... Are the logs not accessible over DECnet? Seems like
you might be going over the river to get the water...?
Johnny
Sampsa
On 15 Aug 2012, at 12:05, Johnny Billquist wrote:
On 2012-08-15 10:57, Sampsa Laine wrote:
Yes, I was aware of the batch submission, but wanted to
do it the "ssh way" for a particular reason..
Ok. Note, however, that the solution you came up with now
is not really generally usable in DECnet, but is rather
VMS-specific. But on the other hand, more or less any
solution will be rather specific...
Not sure that a batch submission is that much different
from your network connection though. Neither is really
similar to an ssh session, unless I'm missing something.
Johnny
Sampsa
On 15 Aug 2012, at 11:55, Johnny Billquist wrote:
On 2012-08-15 08:36, Sampsa Laine wrote:
Guys,
I remember there's a clean / elegant way of telling
another node to run a DCL script for me, but have totally
forgotten how to do it.
Basically, I have three nodes, A, B and C.
I've set up proxies for user FOO across all of them.
Now I want node A (as user FOO) to be able to tell
node B and C to run a script on them, as user FOO.
How do I do this?
I notice that you figured out one way, which is to use
network communication to a named task.
Another is to submit a batch job on another node. A
third is (I seem to remember) the ability to just request a
program to be run on a remote node, but that might some RSX
specific thing. I can check in manuals if you want to know
more, as my memory is fuzzy on the specifics.
Johnny
Sampsa,
For VMS specific you can us SYSMAN. It does NOT require a cluster. It
does require that you specify the username and password of the remote
however.
$ MCR SYSMAN
SYSMAN> set environment/node=<nodename>/user=<username>
Remote Password: <remote accounts password>
SYSMAN> do @foo.com
SYSMAN>
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Sampsa Laine
Sent: Wednesday, August 15, 2012 05:20
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] 'rexec' or 'ssh <command>' over DECNET
Well, the logs are transferred over DECNET to the main host
that runs SSH (the others are too slow to run SSH).
But they are generated by a DCL script on the node from which
they are extracted (basically, DCL scripts are run on KUHAVX
and LABVAX which copy the exported logs to SOLAR5).
So I execute the log generation process (which tells KUHAVX +
LABVAX to export their logs to SOLAR5) and then fetch them
from SOLAR5.
Sampsa
On 15 Aug 2012, at 12:15, Johnny Billquist wrote:
On 2012-08-15 11:09, Sampsa Laine wrote:
I am aware of this - I am using this to pull some logs
from a couple of boxes to another, all VMS.
Eh... Are the logs not accessible over DECnet? Seems like
you might be going over the river to get the water...?
Johnny
Sampsa
On 15 Aug 2012, at 12:05, Johnny Billquist wrote:
On 2012-08-15 10:57, Sampsa Laine wrote:
Yes, I was aware of the batch submission, but wanted to
do it the "ssh way" for a particular reason..
Ok. Note, however, that the solution you came up with now
is not really generally usable in DECnet, but is rather
VMS-specific. But on the other hand, more or less any
solution will be rather specific...
Not sure that a batch submission is that much different
from your network connection though. Neither is really
similar to an ssh session, unless I'm missing something.
Johnny
Sampsa
On 15 Aug 2012, at 11:55, Johnny Billquist wrote:
On 2012-08-15 08:36, Sampsa Laine wrote:
Guys,
I remember there's a clean / elegant way of telling
another node to run a DCL script for me, but have totally
forgotten how to do it.
Basically, I have three nodes, A, B and C.
I've set up proxies for user FOO across all of them.
Now I want node A (as user FOO) to be able to tell
node B and C to run a script on them, as user FOO.
How do I do this?
I notice that you figured out one way, which is to use
network communication to a named task.
Another is to submit a batch job on another node. A
third is (I seem to remember) the ability to just request a
program to be run on a remote node, but that might some RSX
specific thing. I can check in manuals if you want to know
more, as my memory is fuzzy on the specifics.
Johnny
