So what would be your suggestion I do?
Sampsa
On 17 Sep 2011, at 18:30, Mark Wickens wrote:
It's all working nicely, but this is before an AUTOGEN. If I may I'll post the contents of the MODPARAMS.DAT and PARAMS.DAT to see if anyone recognises something bad.
Regards, Mark.
On 17/09/11 11:28, Peter Coghlan wrote:
My apolgies for the confusion Peter. But you're right to assume I meant the
cl.gr.nr.
And yes, there is obviously something wrong here. IF an autogen was done I'd
say have a look at modparams.dat
- alloclass must be unique for each node
- same for tapealloclass
The alloclass is used in forming device names and lock resource names. If it
is not set correctly, there will be problems in these areas but they should not
prevent a node from joining a cluster. I would tend to leave it at zero unless
there were good reasons for changing it. There are myriads of little rules about
how various sysgen parameters should be set but most of them can be ignored
for the moment, partly because VMS is not so fragile that having any one of
a vast number of parameters wrong will prevent a system from booting and partly
because the system picks sensible defaults that will work in typical cases
for sysgen parameters.
More important sysgen parameters to check are SCSNODE and particularly
SCSSYSTEMID. If SCSSYSTEMID was inadvertently changed, this may well cause
difficulties. SCSSYSTEMID must be the same as the decnet area number *1024 plus
the decnet node number. This number is used to calculate the ethernet address
used for cluster communications. It is also used to uniquely identify cluster
nodes to other cluster nodes.
If SCSNODE is changed without changing SCSSYSTEMID or vice versa, that node
will have difficulties joining a cluster as the other nodes in the cluster
will remember the previous values and complain that the new ones are not
consistent. The solution here is to shut down all nodes in the cluster so that
they are all down at the same time and then reboot each.
And check the cluster license. AFAIK the cluster license must bu unique for
each node. Or one license with 0 units and in that case make sure all
nodenames are mentioned in the /INCLUDE list, again on all nodes where the
license was loaded.
I am not 100% sure on this but as far as I know, cluster licenses are not
checked when a node is attempting to join a cluster because the system is
operating at a very low level and may not be in a position to access the disk
yet where its licenses are held. I think the response to lack of cluster
license is whinges about it in the operator log rather than disallowing a
node from joining. If it were to prevent a node from joining, I would expect
to see a prominent error message mentioning a license problem.
Regards,
Peter Coghlan.
It's all working nicely, but this is before an AUTOGEN. If I may I'll post the contents of the MODPARAMS.DAT and PARAMS.DAT to see if anyone recognises something bad.
Regards, Mark.
On 17/09/11 18:15, Sampsa Laine wrote:
Guys,
I hink CHIMPY is running again, please try it out (8.401)...
Sampsa
Well done Sampsa! Woot-woot!
Glad to hear you've had some luck.
I was getting system errors from my VAXstation 4000/60. I've just stripped it down and cleaned it of all dust bunnies, reseated the RAM and contact cleaned all connectors. It was one of the few machines that I didn't do this to when I got it.
So far so good. Just need to find a CDROM drive that works!
Picked up a MicroVAX II today. Have yet to muster up the strength to remove it from the car!
Mark.
WEEEIRD - the SRM is not on serial only, not kbd/monitor as before.
On 17 Sep 2011, at 11:46, Sampsa Laine wrote:
I did, and found a totally superfluous (to my needs) QLogic SCSI card + drive in there.
I've got a KZPAC attached with a BA365 - the machine boots, but just to a blue screen.
With the Qlogic in, it won't even boot.
Is there some magic key setting to reset the SRM ?
Sampsa
On 17 Sep 2011, at 11:40, hvlems at zonnet.nl wrote:
Possibly cards became unseated.
Open it up and remove all boards and reseat them. If that doesn't work.
------Origineel bericht------
Van: Sampsa Laine
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] DS10 fucked - 3 beeps. Any ideas?
Verzonden: 17 september 2011 11:52
Hi,
So I just had my DS10 perfectly configured but on its side, and it fell over.
Now it just gives me 3 beeps.
What do I do, disassemble the whole thing and reseat the RAM or what?
I did, and found a totally superfluous (to my needs) QLogic SCSI card + drive in there.
I've got a KZPAC attached with a BA365 - the machine boots, but just to a blue screen.
With the Qlogic in, it won't even boot.
Is there some magic key setting to reset the SRM ?
Sampsa
On 17 Sep 2011, at 11:40, hvlems at zonnet.nl wrote:
Possibly cards became unseated.
Open it up and remove all boards and reseat them. If that doesn't work.
------Origineel bericht------
Van: Sampsa Laine
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] DS10 fucked - 3 beeps. Any ideas?
Verzonden: 17 september 2011 11:52
Hi,
So I just had my DS10 perfectly configured but on its side, and it fell over.
Now it just gives me 3 beeps.
What do I do, disassemble the whole thing and reseat the RAM or what?
Possibly cards became unseated.
Open it up and remove all boards and reseat them. If that doesn't work.
------Origineel bericht------
Van: Sampsa Laine
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] DS10 fucked - 3 beeps. Any ideas?
Verzonden: 17 september 2011 11:52
Hi,
So I just had my DS10 perfectly configured but on its side, and it fell over.
Now it just gives me 3 beeps.
What do I do, disassemble the whole thing and reseat the RAM or what?
So I just had my DS10 perfectly configured but on its side, and it fell over.
Now it just gives me 3 beeps.
If it's like other alphas, there are different beep sequences that mean
different things and the meanings of some of the more common ones are listed
in the manual.
What do I do, disassemble the whole thing and reseat the RAM or what?
Given what happened, that sounds like a good idea. Also check for connections
that have come loose and for any damage.
If you have a graphics card fitted but no keyboard or mouse plugged in, this
can cause some alphas to beep on startup, but they generally ignore the
problem and continue on booting.
Regards,
Peter Coghlan.
My apolgies for the confusion Peter. But you're right to assume I meant the
cl.gr.nr.
And yes, there is obviously something wrong here. IF an autogen was done I'd
say have a look at modparams.dat
- alloclass must be unique for each node
- same for tapealloclass
The alloclass is used in forming device names and lock resource names. If it
is not set correctly, there will be problems in these areas but they should not
prevent a node from joining a cluster. I would tend to leave it at zero unless
there were good reasons for changing it. There are myriads of little rules about
how various sysgen parameters should be set but most of them can be ignored
for the moment, partly because VMS is not so fragile that having any one of
a vast number of parameters wrong will prevent a system from booting and partly
because the system picks sensible defaults that will work in typical cases
for sysgen parameters.
More important sysgen parameters to check are SCSNODE and particularly
SCSSYSTEMID. If SCSSYSTEMID was inadvertently changed, this may well cause
difficulties. SCSSYSTEMID must be the same as the decnet area number *1024 plus
the decnet node number. This number is used to calculate the ethernet address
used for cluster communications. It is also used to uniquely identify cluster
nodes to other cluster nodes.
If SCSNODE is changed without changing SCSSYSTEMID or vice versa, that node
will have difficulties joining a cluster as the other nodes in the cluster
will remember the previous values and complain that the new ones are not
consistent. The solution here is to shut down all nodes in the cluster so that
they are all down at the same time and then reboot each.
And check the cluster license. AFAIK the cluster license must bu unique for
each node. Or one license with 0 units and in that case make sure all
nodenames are mentioned in the /INCLUDE list, again on all nodes where the
license was loaded.
I am not 100% sure on this but as far as I know, cluster licenses are not
checked when a node is attempting to join a cluster because the system is
operating at a very low level and may not be in a position to access the disk
yet where its licenses are held. I think the response to lack of cluster
license is whinges about it in the operator log rather than disallowing a
node from joining. If it were to prevent a node from joining, I would expect
to see a prominent error message mentioning a license problem.
Regards,
Peter Coghlan.
Hi,
So I just had my DS10 perfectly configured but on its side, and it fell over.
Now it just gives me 3 beeps.
What do I do, disassemble the whole thing and reseat the RAM or what?
