- HECnet - lists @ Update

by HECNET＠beyondthepale.ie

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.

13 years, 10 months

1
0
0 0

I broke CHIMPY, again...

by mark＠wickensonline.co.uk

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.

13 years, 10 months

1
0
0 0

Fwd: Re: [HECnet] More clustering fun

by mark＠wickensonline.co.uk

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

13 years, 10 months

1
0
0 0

Fwd: Re: [HECnet] More clustering fun

by HECNET＠beyondthepale.ie

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.

13 years, 10 months

1
0
0 0

Fwd: Re: [HECnet] More clustering fun

by mark＠wickensonline.co.uk

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.

13 years, 10 months

1
0
0 0

Noob question here: boot flags and such

by sampsa＠mac.com

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.

13 years, 10 months

1
0
0 0

Noob question here: boot flags and such

by sampsa＠mac.com

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.

13 years, 10 months

1
0
0 0

MMSRR (Mandatory Magic Smoke Release Report)

by mark＠wickensonline.co.uk

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.

13 years, 10 months

1
0
0 0

Noob question here: boot flags and such

by sampsa＠mac.com

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.

13 years, 10 months

1
0
0 0

Noob question here: boot flags and such

by HECNET＠beyondthepale.ie

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.

13 years, 10 months

1
0
0 0

Noob question here: boot flags and such

by jeep＠scshome.net

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.

13 years, 10 months

1
0
0 0

Noob question here: boot flags and such

by HECNET＠beyondthepale.ie

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.

13 years, 10 months

1
0
0 0

Off-topic: Pyffle BBC

by wonko＠4amlunch.net

Even more off topic topics. :) A) I've gone and set CircleMUD up again. Running on a Solaris box at the moment but after we move I plan on getting the VAXen set up again at which point I'll move it to one of those. Mud.4amlunch.net port 4000. Prepare to be bored as there are no users yet. :) B) If you've not seen Schemaverse yet I *highly* recommend checking it out. www.schemaverse.com. Quite possibly the craziest and coolest thing I've seen in a while. Space game you play in PostgreSQL. That's my random whatever for the day. :) -brian On Sep 17, 2011, at 15:13, Sampsa Laine <sampsa at mac.com> wrote: 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...

13 years, 10 months

1
0
0 0

Fwd: Re: [HECnet] More clustering fun

by HECNET＠beyondthepale.ie

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 is absolutely right. However, you may need to do an AUTOGEN at some point in the future and it is good to have done one that has worked before then so that there are no surprises. (It should have been possible to get past the joining the cluster problem by doing a conversational boot and setting VAXCLUSTER to 0 so that the original problem could have been found and fixed rather than having to recreate the disk) Regards, Peter Coghlan.

13 years, 10 months

1
0
0 0

All-in-1 kit?

by mark＠wickensonline.co.uk

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. Fred, You can find the kit here: $$ backup/list SLAVE::DECUS$:[DECUS.VAX_MEDIA]A1032.SAV/sav Listing of save set(s) Save set: A1032.SAV Written by: SYSTEM UIC: [000001,000004] Date: 17-SEP-2011 20:16:38.34 Command: BACKUP [.A1032...]*.*; [-]A1032.SAV/SAV Operating system: OpenVMS VAX version V7.3 BACKUP version: V7.3 CPU ID register: 13000202 Node name: _BUBBLE:: Written on: _$255$DKA400: Block size: 32256 Group size: 10 Buffer count: 8

13 years, 10 months

1
0
0 0

Fwd: Re: [HECnet] More clustering fun

by mark＠wickensonline.co.uk

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.

13 years, 10 months

1
0
0 0

Fwd: Re: [HECnet] More clustering fun

by HECNET＠beyondthepale.ie

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.

13 years, 10 months

1
0
0 0

Off-topic: Pyffle BBC

by sampsa＠mac.com

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...

13 years, 10 months

1
0
0 0

Success after a long afternoon...

by mark＠wickensonline.co.uk

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.

13 years, 10 months

1
0
0 0

All-in-1 kit?

by mark＠wickensonline.co.uk

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...

13 years, 10 months

1
0
0 0

All-in-1 kit?

by fcoffey＠misernet.net

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.

13 years, 10 months

1
0
0 0

CHIMPY IS REBORN!

by fcoffey＠misernet.net

On Sat, 17 Sep 2011, Sampsa Laine wrote: I hink CHIMPY is running again, please try it out (8.401)... Works fine from area 33. Fred

13 years, 10 months

1
0
0 0

More clustering fun

by mark＠wickensonline.co.uk

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.

13 years, 10 months

1
0
0 0

More clustering fun

by sampsa＠mac.com

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.

13 years, 10 months

1
0
0 0

Fwd: Re: [HECnet] More clustering fun

by mark＠wickensonline.co.uk

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.

13 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet