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?
Strange indeed. HELP INITIALIZE /STRUCTURE on Alpha VMS 7.3-1 says that VAX
deos not support Structure Level 5 disks, and specifying 5 on VAX results
in an error. I don't have a 7.3 VAX system to hand to check what that says.
The help for MOUNT is silent on the issue.
I wonder what happens if you try to access filenames with ODS-5 specific
features from the VAX side?
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.
Bother! I neglected to include "USE CURRENT" before the SHOW commands!
As result, both BEFORE.TXT and AFTER.TXT ended up listing the "active"
parameter set, ie what is in memory. AUTOGEN, on the other hand updates
the "current" parameter set which is the parameter set on the disk.
Assuming you have now rebooted after the AUTOGEN, if you now repeat:
$ DEFINE /USER SYS$OUTPUT AFTER.TXT
$ MCR SYSGEN
SHOW /ALL
SHOW /SPECIAL
^Z
You should get an updated AFTER.TXT suitable for comparison with BEFORE.TXT
which was generated before the AUTOGEN. This should then reveal the changes
AUTOGEN made.
(It would be unusual for AUTOGEN to result in no changes at all.)
Note that having manually changed the parameters with SYSGEN the system
should be in line with the MODPARAMS file which is what I saw.
But haven't you done an AUTOGEN already as part of the commands I suggested
for comparing the system parameters before and after it? If you have, AUTOGEN
will have set the system parameters taking account of what it found in
MODPARAMS.DAT.
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.
A backup is always good to have.
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
Shouldn't that be /STRUCTURE_LEVEL=2 ? I guess that's what you did and 5 is
a typo?
$ 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.
Good news that everything is working now.
Regards,
Peter Coghlan.
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.
