On 19/09/11 23:04, Sampsa Laine wrote:
This time by adding volume shadowing:
I added the following to MODPARAMS.DAT:
! Volume Shadowing Parameters:
SHADOWING=2 ! Enables phase II shadowing
SHADOW_SYS_DISK=1 ! Enables system disk shadowing
SHADOW_SYS_UNIT=7 ! Specifies 7 as the virtual unit number
of the system disk
SHADOW_MAX_COPY=3 ! Specifies that 3 parallel copies can occur at one time
SHADOW_MBR_TMO=10 ! Allows 10 seconds for physical members to fail over
! before removal from the shadow set
Then ran:
@SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS FEEDBACK
Rebooted with save feedback, when it comes up, it fails:
**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
** Bugcheck code = 00000B14: SHDWREQALLOC, Allocation class is required for shadow set members
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: CHIMPY
** Supported CPU count: 00000001
** Active CPUs: 00000000.00000001
** Current Process: SYSINIT
** Current PSB ID: 00000001
** Image Name: SYSINIT.EXE
Easiest way to fix?
You need to add an ALLOCLASS definition to MODPARAMS.DAT, or use SYSGEN to define, for example:
$ MCR SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET ALLOCLASS 100
SYSGEN> WRITE CURRENT
Ctrl-Z
then reboot. If you use SYSGEN then make MODPARAMS.DAT match.
You'll probably need a conversational boot to get this point.
See here: http://lakesdev.blogspot.com/2009/09/volume-shadowing-system-disk-on-vax.ht…
Mark.
On 19/09/11 11:40, Peter Coghlan wrote:
Peter, I should be able to get round to testing this today.
Great stuff. Let me know how you get on and I will try to help if
necessary / possible.
Just currently moving the system disk on the alpha from ODS-5 to OSD-2 so
that we've got half a chance of clustering the VAX properly...
I don't think the alpha system disk being ODS-5 should cause any problems
clustering with a VAX. However, you would not be able to mount the ODS-5
disk from the VAX side of the cluster and from that point of view, it would
be better if it was ODS-2.
Regards,
Peter Coghlan.
Weird, however, that I can mount an ODS-5 drive on the VAX and indeed do directory listings and the like. Wouldn't believe it if I hadn't seen it. Is it some feature of 7.3.1 that I didn't know about? Or maybe specific to mounting drives in a cluster?
Regarding AUTOGEN - I tried what you suggested and there were no differences between the before and after files. I can post them if you like, but I'm not sure they are going to be much use.
Note that having manually changed the parameters with SYSGEN the system should be in line with the MODPARAMS file which is what I saw.
I'm going to back up the ALPHASYSTEM disk when it's offline and then I'll try an AUTOGEN and see what happens this time. Maybe it was something else which is now working. With a backup it will be trivial to revert.
The system disk move from ODS-5 to OSD-2 was uneventful. I created an extra shadow member $4$DKC500: in shadowset DSA0: which was running on $4$DKB0: and $4$DKB100:, then I dismounted the new member $4$DKC500: and $4$DKB100:. I then followed the instructions here: http://h71000.www7.hp.com/doc/73final/6536/6536pro_001.html
Which went something like this:
$ INITIALIZE /STRUCTURE_LEVEL=5 $4$DKB100: SLAVESYSTEM
$ MOUNT/FOREIGN $4$DKB100:
$ BACKUP/LOG/CONVERT/IMAGE $4$DKC500: $4$DKB100:/NOINIT
then shutdown the system, swapped $4$DKB0: and $4$DKB100: so the OSD-2 drive was now the single shadow set member, rebooted then issued a
$ MOUNT/SYSTEM DSA0: /SHADOW=($4$DKB0:, $4$DKB100:) SLAVESYSTEM SYSTEM$
to bring $4$DKB100: (the old ODS-5 drive) back into the shadowset via copy.
The ALPHA and VAX are now clustered nicely, including a common SYSAUTH and RIGHTSLIST, so I can now login to my normal account hosted on the ALPHA from the VAX. I've also pulled out common logicals and mounts into a common file.
Good progress today.
Regards, Mark
Peter, I should be able to get round to testing this today.
Great stuff. Let me know how you get on and I will try to help if
necessary / possible.
Just currently moving the system disk on the alpha from ODS-5 to OSD-2 so
that we've got half a chance of clustering the VAX properly...
I don't think the alpha system disk being ODS-5 should cause any problems
clustering with a VAX. However, you would not be able to mount the ODS-5
disk from the VAX side of the cluster and from that point of view, it would
be better if it was ODS-2.
Regards,
Peter Coghlan.
Peter, I should be able to get round to testing this today.
Just currently moving the system disk on the alpha from ODS-5 to OSD-2 so that we've got half a chance of clustering the VAX properly...
Mark.
On Sat, 17 Sep 2011, 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.
That was meant for Steve Davidson :)
Sampsa
On 19 Sep 2011, at 00:50, Sampsa Laine wrote:
Let me know if you're logging in today, have a quick chat.
Might be awake :)
Sampsa
On 18 Sep 2011, at 14:42, Steve Davidson wrote:
Actually,
I would use:
$ set default sys$system
$ mcr sysgen
use current
set startup_p1 ""
write current
exit
$ reboot
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Peter Coghlan
Sent: Sunday, September 18, 2011 08:42
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Noob question here: boot flags and such
I've set my boot_flags to 0,0 in SRM, but it boots to a minimal DCL
shell where I have to type @SYS$SYSTEM:STARTUP to get the ball rolling
How do I stop this?
At some point in the past, you probably did a SET /STARTUP OPA0: in a
conversational boot and omitted to do a SET WRITESYSPARAMS 0 afterwards.
To put things back the way they were, do another conversational boot
ie BOOT -fl 0,1
At the SYSBOOT> prompt, issue the commands:
SET /STARTUP SYS$SYSTEM:STARTUP.COM
CONTINUE
Next time you boot, you should get the full startup automatically.
Regards,
Peter Coghlan.
Let me know if you're logging in today, have a quick chat.
Might be awake :)
Sampsa
On 18 Sep 2011, at 14:42, Steve Davidson wrote:
Actually,
I would use:
$ set default sys$system
$ mcr sysgen
use current
set startup_p1 ""
write current
exit
$ reboot
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Peter Coghlan
Sent: Sunday, September 18, 2011 08:42
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Noob question here: boot flags and such
I've set my boot_flags to 0,0 in SRM, but it boots to a minimal DCL
shell where I have to type @SYS$SYSTEM:STARTUP to get the ball rolling
How do I stop this?
At some point in the past, you probably did a SET /STARTUP OPA0: in a
conversational boot and omitted to do a SET WRITESYSPARAMS 0 afterwards.
To put things back the way they were, do another conversational boot
ie BOOT -fl 0,1
At the SYSBOOT> prompt, issue the commands:
SET /STARTUP SYS$SYSTEM:STARTUP.COM
CONTINUE
Next time you boot, you should get the full startup automatically.
Regards,
Peter Coghlan.
Fired up the newly acquired MicroVAX II today. Twice in fact. First time just to see if it did anything at all. Which it did - power supply kicked in, hard drive span up, I could see lights on the cards.
Second time after connecting a console I fired it up whilst looking at the boot sequence LED on the back - went 9, 7, 6, 5, 4, 3, 2, then back to 8. It's possible the console wasn't connected properly - I think I should have seen the CPU model by this point on the console.
Then the magic smoke let go. Prime candidate for smoke release are the mains filtering capacitors, but I've not extracted the power supply so cannot be sure.
I'm getting a talent for blowing up power supplies these days...
Mark.
That worked! Thanks guys.
Sampsa
On 18 Sep 2011, at 15:29, Peter Coghlan wrote:
Actually,
I would use:
$ set default sys$system
$ mcr sysgen
use current
set startup_p1 ""
write current
exit
$ reboot
The original poster said it boots to a minimal DCL shell. That sounds like
a $ prompt to me. You get left at a $ prompt when SET /STARTUP has been set
to OPA0:. You don't get a $ prompt when STARTUP_P1 is set to "MIN" - you have
to log in as usual.
He also stated that entering @SYS$SYSTEM:STARTUP manually fixed the problem.
If STARTUP_P1 was set to "MIN" then entering @SYS$SYSTEM:STARTUP would not
undo its effects and he would be left back where he started.
It looks more likely to me that SET /STARTUP is the setting that has been
modified not the STARTUP_P1 parameter.
Rather than do a conversational boot, he could do:
$ mcr sysgen
use current
set /startup sys$system:startup.com
write current
exit
$ reboot
For some reason, that method did not occur to me earlier.
Regards,
Peter Coghlan.
Actually,
I would use:
$ set default sys$system
$ mcr sysgen
use current
set startup_p1 ""
write current
exit
$ reboot
The original poster said it boots to a minimal DCL shell. That sounds like
a $ prompt to me. You get left at a $ prompt when SET /STARTUP has been set
to OPA0:. You don't get a $ prompt when STARTUP_P1 is set to "MIN" - you have
to log in as usual.
He also stated that entering @SYS$SYSTEM:STARTUP manually fixed the problem.
If STARTUP_P1 was set to "MIN" then entering @SYS$SYSTEM:STARTUP would not
undo its effects and he would be left back where he started.
It looks more likely to me that SET /STARTUP is the setting that has been
modified not the STARTUP_P1 parameter.
Rather than do a conversational boot, he could do:
$ mcr sysgen
use current
set /startup sys$system:startup.com
write current
exit
$ reboot
For some reason, that method did not occur to me earlier.
Regards,
Peter Coghlan.
Actually,
I would use:
$ set default sys$system
$ mcr sysgen
use current
set startup_p1 ""
write current
exit
$ reboot
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Peter Coghlan
Sent: Sunday, September 18, 2011 08:42
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Noob question here: boot flags and such
I've set my boot_flags to 0,0 in SRM, but it boots to a minimal DCL
shell where I have to type @SYS$SYSTEM:STARTUP to get the ball rolling
How do I stop this?
At some point in the past, you probably did a SET /STARTUP OPA0: in a
conversational boot and omitted to do a SET WRITESYSPARAMS 0 afterwards.
To put things back the way they were, do another conversational boot
ie BOOT -fl 0,1
At the SYSBOOT> prompt, issue the commands:
SET /STARTUP SYS$SYSTEM:STARTUP.COM
CONTINUE
Next time you boot, you should get the full startup automatically.
Regards,
Peter Coghlan.
