Tried that, and STREAM_CR - the files were created on OS X which is Unix-y.
Oh well, got it going in the end - won't let the damn things expire again so that reloading them is easier.
BTW, does someone have a license database pruner that'll kill expired licenses?
Sampsa
On 20 Aug 2012, at 17:22, Peter Coghlan wrote:
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.
If the files were created on windows which tends to like CRLF delimited files,
maybe something like:
$ MOUNT DQB1: /MEDIA=CDROM/OVER=ID/UNDEF=(STREAM:132)
would work better?
If this is not the case, more information about the way the files were created
and what the weird DCL errors were would be helpful.
Regards,
Peter Coghlan.
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.
If the files were created on windows which tends to like CRLF delimited files,
maybe something like:
$ MOUNT DQB1: /MEDIA=CDROM/OVER=ID/UNDEF=(STREAM:132)
would work better?
If this is not the case, more information about the way the files were created
and what the weird DCL errors were would be helpful.
Regards,
Peter Coghlan.
Well, after all that, I'm happy to announce that RHESUS and CHIMPY are back online.
RHESUS has a fairly large file library available, including a whole bunch of SPDs..
Sampsa
On 20 Aug 2012, at 15:01, Sampsa Laine wrote:
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.
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
