No because it is a property of the hardware front-end.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Sampsa Laine
Sent: Tuesday, September 20, 2011 14:23
To: hecnet at Update.UU.SE
Subject: [HECnet] SRM stuff from VMS
Is there a way of setting the bootdev and bootflags from within VMS?
Walking to the next room and plugging in a serial cable is a pain?
Sampsa
boot -fl 0,1
SYSBOOT>set alloclass=<non-zero-value>
SYSBOOT>continue
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Sampsa Laine
Sent: Monday, September 19, 2011 21:16
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] I broke CHIMPY, again...
How do I get the system to boot again, easiest way?
Sampsa
On 20 Sep 2011, at 02:07, Steve Davidson wrote:
You will need to set ALLOCLASS (in MODPARAMS.DAT) to non-zero, autogen, and reboot. Do not use feedback unless the system had been up for at least 24 hours.
-Steve
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Sampsa Laine
Sent: Monday, September 19, 2011 18:05
To: hecnet at Update.UU.SE
Subject: [HECnet] I broke CHIMPY, again...
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?
How do I get the system to boot again, easiest way?
Conversational, set SHADOW_SYS_DISK and
SHADOW_SYS_UNIT to zero. Then check the
documentation about SHADOW_SYS_UNIT.
--
Regards, Rok
You will need to set ALLOCLASS (in MODPARAMS.DAT) to non-zero, autogen, and reboot. Do not use feedback unless the system had been up for at least 24 hours.
-Steve
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Sampsa Laine
Sent: Monday, September 19, 2011 18:05
To: hecnet at Update.UU.SE
Subject: [HECnet] I broke CHIMPY, again...
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?
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.
