I have a customer running a 44 node QNX4.24 network
When they do a licinfo -N
They get all nodes listed except node 44.
What types of things should I look for to resolve this ???
- Thanks,
Kevin
Kevin Warkentin <kevin.p.warkentin@ca.abb.com> wrote:
I have a customer running a 44 node QNX4.24 network
When they do a licinfo -N
They get all nodes listed except node 44.
They don’t have a license for node 44? Can they see node 44
from the node they are doing the licinfo on? (Does sin -n 44
work?)
-David
QNX Training Services
dagibbs@qnx.com
Pardon my butting in; I tried this here and got equally bizarre
results. Node 1,3,4 & 7 were active. From node 3, all that showed
up from node 3 were nodes 3 & 7. No node shows all the others. No
node reports a qnx license.
We are running the latest patchE and tcpip5.
Richard
David Gibbs wrote:
Kevin Warkentin <> kevin.p.warkentin@ca.abb.com> > wrote:
I have a customer running a 44 node QNX4.24 network
When they do a licinfo -N
They get all nodes listed except node 44.They don’t have a license for node 44? Can they see node 44
from the node they are doing the licinfo on? (Does sin -n 44
work?)-David
QNX Training Services
dagibbs@qnx.com
David:
Yes node 44 has a QNX license . Node 44 is seen from the node they perform
the command on.
Out of curiosity I tried the same command on a 3 node system I have
running in our lab.
I have 3 QNX 4.25 nodes and when I do a licinfo -N
it only shows the first two nodes. It omits the last node on the network.
a sin net shows all three nodes.
An examination of .licnses on all three nodes proves okay. All three nodes
have license entries.
So maybe there is a bug regarding the last node on a network ?
This seems to be in QNX 4.25 and qnx 4.24.
- Kevin
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:99dcek$ai8$5@nntp.qnx.com…
Kevin Warkentin <> kevin.p.warkentin@ca.abb.com> > wrote:
I have a customer running a 44 node QNX4.24 network
When they do a licinfo -N
They get all nodes listed except node 44.They don’t have a license for node 44? Can they see node 44
from the node they are doing the licinfo on? (Does sin -n 44
work?)-David
QNX Training Services
dagibbs@qnx.com
Kevin Warkentin <kevin.p.warkentin@ca.abb.com> wrote:
David:
Yes node 44 has a QNX license . Node 44 is seen from the node they perform
the command on.
Out of curiosity I tried the same command on a 3 node system I have
running in our lab.
I have 3 QNX 4.25 nodes and when I do a licinfo -N
it only shows the first two nodes. It omits the last node on the network.
a sin net shows all three nodes.
An examination of .licnses on all three nodes proves okay. All three nodes
have license entries.
So maybe there is a bug regarding the last node on a network ?
This seems to be in QNX 4.25 and qnx 4.24.
Just checked the source for licinfo. There’s a (<max_node) rather than
(<=max_node) test for a loop. Yup, it will always forget the last node.
-David
QNX Training Services
dagibbs@qnx.com
David Gibbs <dagibbs@qnx.com> wrote:
This seems to be in QNX 4.25 and qnx 4.24.
Just checked the source for licinfo. There’s a (<max_node) rather than
(<=max_node) test for a loop. Yup, it will always forget the last node.
I’ve issued a PR against this – but its going to be a low priority
fix, as it is only on the reporting side, not on the licensing.
-David
QNX Training Services
dagibbs@qnx.com
David Gibbs <> dagibbs@qnx.com> > wrote:
This seems to be in QNX 4.25 and qnx 4.24.Just checked the source for licinfo. There’s a (<max_node) rather
than
(<=max_node) test for a loop. Yup, it will always forget the last
node.
I’ve issued a PR against this – but its going to be a low priority
fix, as it is only on the reporting side, not on the licensing.
I’ve always thought that problem reports should be weighted by
complexity of resolution, such that even if the defect outcome is
non-critical, if it can be resolved by changing 1 byte in the source, it
moves fairly high up the todo list. If nothing else, this gives the
developer working on a “real” problem (one that might take weeks to
resolve), some sense of accomplishment for the day (yup, I closed out a
PR in 3 seconds flat today - 10 seconds if you include check-out and
check-in time 
Rennie Allen <RAllen@csical.com> wrote:
David Gibbs <> dagibbs@qnx.com> > wrote:
I’ve issued a PR against this – but its going to be a low priority
fix, as it is only on the reporting side, not on the licensing.I’ve always thought that problem reports should be weighted by
complexity of resolution, such that even if the defect outcome is
non-critical, if it can be resolved by changing 1 byte in the source, it
moves fairly high up the todo list. If nothing else, this gives the
developer working on a “real” problem (one that might take weeks to
resolve), some sense of accomplishment for the day (yup, I closed out a
PR in 3 seconds flat today - 10 seconds if you include check-out and
check-in time >
You’ve got to weigh that against the nagging pain of knowing it’s
fixed, but people keep running into it, and there ain’t an update
going out for three months.
Things like this should be saved for a `frolic’ week shortly
before an update is scheduled
Rennie Allen <RAllen@csical.com> wrote:
David Gibbs <> dagibbs@qnx.com> > wrote:
This seems to be in QNX 4.25 and qnx 4.24.Just checked the source for licinfo. There’s a (<max_node) rather
than
(<=max_node) test for a loop. Yup, it will always forget the last
node.I’ve issued a PR against this – but its going to be a low priority
fix, as it is only on the reporting side, not on the licensing.I’ve always thought that problem reports should be weighted by
complexity of resolution, such that even if the defect outcome is
non-critical, if it can be resolved by changing 1 byte in the source, it
moves fairly high up the todo list. If nothing else, this gives the
developer working on a “real” problem (one that might take weeks to
resolve), some sense of accomplishment for the day (yup, I closed out a
PR in 3 seconds flat today - 10 seconds if you include check-out and
check-in time >
Its a good thought - priority given to fixing problems ought to be a
reflection of not only the benefit of fixing the problem but also the
cost (inclusive of the costs of risk mitigation - testing etc).
Our defect tracking system allows us to distinguish between criticality
and priority so that we can do just this sort of thing. It isn’t
a critical problem, but if we can fix it with minimal effort and risk,
it will get looked at sooner than it would if it involved a great deal
of effort or risk.
–
Eric Johnson
QA Mgr, QNX Software Systems Ltd.
pete@spam-yourself.com wrote:
You’ve got to weigh that against the nagging pain of knowing it’s
fixed, but people keep running into it, and there ain’t an update
going out for three months.Things like this should be saved for a `frolic’ week shortly
before an update is scheduled >
Problem is, that week will likely be filled with frantic
activity to test & nail down major bugs!
Or a whole lot of beer drinking, if you didn’t let feature creep take
hold; either way, the little bugs might be neglected…
-----Original Message-----
From: Alex [mailto:acellarius@systems104.co.za]
Posted At: Tuesday, March 27, 2001 12:58 PM
Posted To: qnx4
Conversation: Licinfo not showing all nodes
Subject: Re: Licinfo not showing all nodes
pete@spam-yourself.com wrote:
You’ve got to weigh that against the nagging pain of knowing it’s
fixed, but people keep running into it, and there ain’t an update
going out for three months.Things like this should be saved for a `frolic’ week shortly
before an update is scheduled >
Problem is, that week will likely be filled with frantic
activity to test & nail down major bugs!