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
On 2013-02-13 00:51, Clem Cole wrote:
On Tue, Feb 12, 2013 at 3:54 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
Nope. The 11/60 wasn't a big flop. It wasn't a success, admittedly,
but it did sell in some numbers. (I at one time, had four 11/60
machines to play with in a computer club, and I still have a
complete CPU board set for an 11/60 - no WCS though.)
The limited success of the 11/60 was due to the totally
incomprehensible decision to go for 11/34 feature parity at a time
when the 11/70 had already set the future standard.
But apart from that stupidity, it was a rather nice machine, in a
very nice package.
I still occasionally still see product manager for it, socially. He
was the one that told me that it was the fastest from release to EOL.
I once asked him about why the 40/34 not the 45/55/70 [i.e. at least add
the 17th bit - I/D] space, and he told me that the 60 was marketed to be
a small business machine -i.e. going up against the Burroughs B1700 and
IBMs System 34 and 38. WCS was so they could have special uCode for
different languages such as RSTS Cobol something both IBM and Burroughs
were making a big deal about (the B1700 switched it ucode on the fly -
actually very cool machine). Anyway, he once told me that marketing was
afraid that people that we buying 11/70s would go for the 60 if it I/D
space (what they would later do with the 11/44).
Well, the 11/70 easily outlived the 11/44, in that 11/70 machines were still sold after the 11/44 was terminated, as far as I know.
Speed was probably the biggest reason for that. Although the RH70 probably played a small part as well.
I even seem to remember that at one point DEC believed they had to stop the 11/70 because of emission regulations. But the 11/70 came back in the corporate cabinet for that.
As for speed from release to EOL, can anything beat the 11/74? It came as far as field test before withdrawn, although a few machines survived for many, many years inside DEC. In essence, the machine existed, but was EOLed before hitting market.
By the way, Paul claimed TRAX was the fastest from release to EOL. But as far as I know, TRAX never had a dedicated machine, so it's a little like comparing apples to oranges. TRAX was software. Intended to run on the 11/70 as far as I know. But with special terminals (the VT61). Those terminals gotta have been EOLed pretty fast after launch, though.
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
