If you have registered and loaded the licenses successfully, but still DECnet-OSI won't start, you might have too few license units for the system type.
Can you tell a bit more about your system and the licenses you are trying to use. THat would be helpful.
On 13.2.2013 6:50, Cory Smelosky wrote:
On 12 Feb 2013, at 23:46, Kari Uusim ki <uusimaki at exdecfinland.org> wrote:
You are not trying to use VMS licenses on Tru64unix, are you?
They aren't compatible, unfortunately. You need real Tru64 licenses.
I am using Tru64 licenses...I just don't know the license names I need...the documentation seems to not be fond of saying...
Kari
On 13.2.2013 4:56, Cory Smelosky wrote:
Hello!
I'm been playing with Tru64 and I managed to get DECnet
installed...some common library files referred to DECNET-OSI-END and
DECNET-OSI-EXT, are these the correct licenses, or need I load others?
NCL continues to complain despite having those licenses loaded.
Any help appreciated...
.
.
On 12 Feb 2013, at 23:58, Dave McGuire <mcguire at neurotica.com> wrote:
On 02/12/2013 11:54 PM, Cory Smelosky wrote:
You are not trying to use VMS licenses on Tru64unix, are you?
They aren't compatible, unfortunately. You need real Tru64
licenses.
I am using Tru64 licenses...I just don't know the license names
I need...the documentation seems to not be fond of saying...
Can you run "strings" on the binary and see if you can find out
what it wants?
Ran it on the binaries, the libraries, and finally found the licenses
mentioned in a shell script that is part of the kernel module rebuild
procedure. I loaded those and NCL still complains...maybe I need to
reinstall the subsets?
This ain't Windows, man. There's gotta be something else going on.
Maybe I need to recompile the kernel? ;)
I think there is an in-kernel license cache of some sort...perhaps not having the licenses loaded at install affected the way the module was built?
Has to either be that, a trailing space, or incorrect license names.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 02/12/2013 11:54 PM, Cory Smelosky wrote:
You are not trying to use VMS licenses on Tru64unix, are you?
They aren't compatible, unfortunately. You need real Tru64
licenses.
I am using Tru64 licenses...I just don't know the license names
I need...the documentation seems to not be fond of saying...
Can you run "strings" on the binary and see if you can find out
what it wants?
Ran it on the binaries, the libraries, and finally found the licenses
mentioned in a shell script that is part of the kernel module rebuild
procedure. I loaded those and NCL still complains...maybe I need to
reinstall the subsets?
This ain't Windows, man. There's gotta be something else going on.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 12 Feb 2013, at 23:51, Dave McGuire <mcguire at neurotica.com> wrote:
On 02/12/2013 11:50 PM, Cory Smelosky wrote:
You are not trying to use VMS licenses on Tru64unix, are you? They
aren't compatible, unfortunately. You need real Tru64 licenses.
I am using Tru64 licenses...I just don't know the license names I
need...the documentation seems to not be fond of saying...
Can you run "strings" on the binary and see if you can find out what
it wants?
Ran it on the binaries, the libraries, and finally found the licenses mentioned in a shell script that is part of the kernel module rebuild procedure. I loaded those and NCL still complains...maybe I need to reinstall the subsets?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 02/12/2013 11:50 PM, Cory Smelosky wrote:
You are not trying to use VMS licenses on Tru64unix, are you? They
aren't compatible, unfortunately. You need real Tru64 licenses.
I am using Tru64 licenses...I just don't know the license names I
need...the documentation seems to not be fond of saying...
Can you run "strings" on the binary and see if you can find out what
it wants?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 12 Feb 2013, at 23:46, Kari Uusim ki <uusimaki at exdecfinland.org> wrote:
You are not trying to use VMS licenses on Tru64unix, are you?
They aren't compatible, unfortunately. You need real Tru64 licenses.
I am using Tru64 licenses...I just don't know the license names I need...the documentation seems to not be fond of saying...
Kari
On 13.2.2013 4:56, Cory Smelosky wrote:
Hello!
I'm been playing with Tru64 and I managed to get DECnet
installed...some common library files referred to DECNET-OSI-END and
DECNET-OSI-EXT, are these the correct licenses, or need I load others?
NCL continues to complain despite having those licenses loaded.
Any help appreciated...
.
You are not trying to use VMS licenses on Tru64unix, are you?
They aren't compatible, unfortunately. You need real Tru64 licenses.
Kari
On 13.2.2013 4:56, Cory Smelosky wrote:
Hello!
I'm been playing with Tru64 and I managed to get DECnet
installed...some common library files referred to DECNET-OSI-END and
DECNET-OSI-EXT, are these the correct licenses, or need I load others?
NCL continues to complain despite having those licenses loaded.
Any help appreciated...
.
Hello!
I'm been playing with Tru64 and I managed to get DECnet
installed...some common library files referred to DECNET-OSI-END and
DECNET-OSI-EXT, are these the correct licenses, or need I load others?
NCL continues to complain despite having those licenses loaded.
Any help appreciated...
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist
Sent: Tuesday, February 12, 2013 15:48
To: hecnet at Update.UU.SE
Cc: lee.gleason at comcast.net
Subject: Re: [HECnet] NT 4 on AlphaServer es40
On 2013-02-12 17:18, lee.gleason at comcast.net wrote:
Speaking of IAS, it really looks cool when reading specs,
but I've
never >touched it, and another aspect of those specs is
that it looks
like it >would be rather slow...
I managed an IAS system on an 11/70 back in the day. I
don't have
any formal benchmarks, but it didn't "feel" any slower than
equivalent
RSX11M and M+ systems I have been on.
Cool. The reason I mentioned it because of just such things
as you mention below - device drivers being full blown tasks
do imply quite a lot more overhead.
IAS was a real treat. If you wanted them, you could
SYSGEN in real
timesharing features for supporting users who didn't
require realtime
response to their needs. It included lots of concepts that
later made
their way into VMS, (although, considering this crowd, I
don't know if
that will be considered a plus here...).
Well, I for one don't mind VMS, even if I think RSX is way
cooler most of the time.
The most interesting feature for me was the way device drivers
worked. Called "handlers", they were complete tasks, instead of the
APR and a couple registers' worth of context provided by
RSX11M/M+ drivers.
You could do a lot more work in them, a lot easier than on
the other
RSX variants. The down side is that any driver action involved
scheduling a task rather than the lightweight context
switch required by a driver.
But, having said that, the system I managed supported lots
and lots of
terminals at 9600 baud, and wasn't bogged down by servicing
interrupts, so scheduling a task to do IO didn't turn out as bad as
you'd think it would.
Yeah. After having done a lot of device drivers and stuff in
-11M+, I sometimes long for the freedom of a task context.
That's when you go diving into ACPs, but it would be nicer if
the driver was a task in itself.
I managed RSTS sytstems as well and I vastly preferred
the richer
environment provide by IAS. I recall being at the DECUS Symposium
where the future of IAS was announced (that is, no
future...). There
was much lamentation, gnashing of teeth and rending of
garments over that.
Support did actually continue for quite a few years after
that though
- turns out that the US Air Force was a big IAS user, and
DEC didn't
want to upset the government.
BTW, I'm always looking for IAS related "stuff" - copies of the
DeVIAS newsletter, IAS software (espcially DECnet-IAS) and the like.
I believe IAS never went to Mentec, but actually stayed with
DEC, for the very same reason (although I also heard that
supposedly it was IRS, but urban legends are probably abundant).
IAS-11 never went to Mentec. Too many government accounts (both US and
others).
-Steve
Never seen TRAX in real life either, btw. What was so
good about it?
Me neither, though I did use some of the VT61 and VT62 terminals
that were developed for it - like VT-52s, but with IBM style block
mode. Not a lot of software outside of TRAX used their block mode
features, so they were pretty rare.
The VT61... The VT62 was a different beast, and I had one for
many years... It's basically a VT52 with inverse video attribute.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com
Sent: Tuesday, February 12, 2013 12:45
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] NT 4 on AlphaServer es40
On Feb 12, 2013, at 12:38 PM, Clem Cole wrote:
On Tue, Feb 12, 2013 at 11:47 AM,
<Paul_Koning at dell.com<mailto:Paul_Koning at dell.com>> wrote:
Nothing. It was one of the most spectacular failures in DEC
history. A whole new OS (well, based on RSX I believe) and
new hardware designed specifically for it (VT62), canceled a
week after it was first announced.
Interesting, I always though the 11/60 held that honor.
Hm... All I know about the 11/60 is that there were a few of
them around the building I worked. One of them was used by
WPS-8 development (running RSTS) -- because the 11/60 was the
fastest PDP-8 ever built thanks to custom microcode that
implemented PDP-8 emulation.
paul
The PDP-11 FORTRAN development group used the 11/60 to run RSTS on.
-Steve
