On 17/09/11 20:22, Peter Coghlan 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.
So, how did you get from where you were to where you are now? Have you
recreated the system disk and got back to the point before you did the AUTOGEN?
If so and you suspect AUTOGEN is going to mess things up again, then
I suggest you record the system parameters before and after the AUTOGEN
(AUTOGEN without the shutdown and reboot phases, that is) and compare them.
Something like this:
$ DEFINE /USER SYS$OUTPUT BEFORE.TXT
$ MCR SYSGEN
SHOW /ALL
SHOW /SPECIAL
^Z
$
$ @SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS NOFEEDBACK
$
$ DEFINE /USER SYS$OUTPUT AFTER.TXT
$ MCR SYSGEN
SHOW /ALL
SHOW /SPECIAL
^Z
$
$ DIFF BEFORE.TXT AFTER.TXT
$
If everything looks ok, you can then reboot to get the new sysgen parameters
take effect. If not, you have an opportunity to fix things before the
shutdown and reboot makes things much more difficult to fix.
Regards,
Peter Coghlan.
Hi Peter,
I will do as you suggest. I have a disk in the box itself which is where the basis for the disk served by SLAVE comes from. So when I got to an unbootable state I have had to restore the disk.
My good friend Malcolm suggested the following which is what worked with me without having to autogen:
On 16/09/11 16:55, Malcolm Blunden wrote: Votes:
Why do you run Autogen afterwards? A change of votes doesn't need any other change that I can think of. How are you changing the votes? Do you understand the arcane use of CURRENT and ACTIVE by SYSGEN? To set the votes to zero in a way that will apply at the next reboot, do
$ MCR SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET VOTES 0
SYSGEN> WRITE CURRENT
SYSGEN> ^Z
That should fix it. Let me know if it doesn't work!
- Malcolm.
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.
So, how did you get from where you were to where you are now? Have you
recreated the system disk and got back to the point before you did the AUTOGEN?
If so and you suspect AUTOGEN is going to mess things up again, then
I suggest you record the system parameters before and after the AUTOGEN
(AUTOGEN without the shutdown and reboot phases, that is) and compare them.
Something like this:
$ DEFINE /USER SYS$OUTPUT BEFORE.TXT
$ MCR SYSGEN
SHOW /ALL
SHOW /SPECIAL
^Z
$
$ @SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS NOFEEDBACK
$
$ DEFINE /USER SYS$OUTPUT AFTER.TXT
$ MCR SYSGEN
SHOW /ALL
SHOW /SPECIAL
^Z
$
$ DIFF BEFORE.TXT AFTER.TXT
$
If everything looks ok, you can then reboot to get the new sysgen parameters
take effect. If not, you have an opportunity to fix things before the
shutdown and reboot makes things much more difficult to fix.
Regards,
Peter Coghlan.
Speaking of masochism, I've released a pre-built VM with a very alpha version of my BBS, pyffle:
Pyffle BBS: http://www.uuhec.net/pyffle-bbs/
Demo version running: telnet://pyffle.sampsa.com
``
VM download (pretty big, for the seriously into UUUP etc enthusiastic): http://pyffle.org/dev_pyffle_v0.1_masochist_edition.zip
Sampsa
On 17 Sep 2011, at 19:22, Mark Wickens wrote:
On 17/09/11 19:21, Fred wrote:
Hi all:
I'd like to slap All-in-1 on my VAX. (yes, I'm a masochist)
Anyone have the kit available via HECnet? Or, alternatively you can deposit it on FRUGAL::
Thanks,
Fred
----
Lets call it for what it is - "legacy" is a term that people use in a
polite but derogatory manner to imply that the future direction they
prefer is not that which they view as the current direction.
ALLIN1 is fun!
As you say, for masochists.
I have it on SLAVE, I'll move it so it's available from the default account...
Well,
Installing OpenVMS on a VAXstation 4000/60 has taken me all afternoon on and off...
I almost gave up. I kept getting 'medium has gone offline' errors with the first hard drive I tried, so I swapped it for another drive, same issue, thought the CDROM must be dodgy, swapped that out, same problem, eventually went back to the original hard drive (which was ZEN's page/swap drive, so easily recreated) and everything is fine. So that is *two* hard drives exhibiting the same problem. Bought from the same ebayer, they were original DEC drives.
So sometimes perseverance does pay off.
I was also getting a system board error to do with NVRAM, so I swapped out the TOY chip, still got the error first reboot, but after that it was fine.
Mark.
On 17/09/11 19:21, Fred wrote:
Hi all:
I'd like to slap All-in-1 on my VAX. (yes, I'm a masochist)
Anyone have the kit available via HECnet? Or, alternatively you can deposit it on FRUGAL::
Thanks,
Fred
----
Lets call it for what it is - "legacy" is a term that people use in a
polite but derogatory manner to imply that the future direction they
prefer is not that which they view as the current direction.
ALLIN1 is fun!
As you say, for masochists.
I have it on SLAVE, I'll move it so it's available from the default account...
Hi all:
I'd like to slap All-in-1 on my VAX. (yes, I'm a masochist)
Anyone have the kit available via HECnet? Or, alternatively you can deposit it on FRUGAL::
Thanks,
Fred
----
Lets call it for what it is - "legacy" is a term that people use in a
polite but derogatory manner to imply that the future direction they
prefer is not that which they view as the current direction.
On 17/09/11 18:39, Sampsa Laine wrote:
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.
Sorry Sampsa, you've got the wrong end of the stick! I'm still talking about my system.
If you want me to have a dig around yours I'd be happy to oblige,
Do I still have an account on CHIMPY?
Mark.
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.
