Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

Computers are like air conditioners. Both stop working, if you open windows. -- Adam Heath


computers / comp.sys.dec / running VMS on PWS (SRM console)

SubjectAuthor
* running VMS on PWS (SRM console)Phillip Helbig (undress to reply
+* Re: running VMS on PWS (SRM console)Phillip Helbig (undress to reply
|`* Re: running VMS on PWS (SRM console)Phillip Helbig (undress to reply
| `* recognizing SCSI disksPhillip Helbig (undress to reply
|  +- Re: recognizing SCSI disksPhillip Helbig (undress to reply
|  `* Re: recognizing SCSI disksDave Froble
|   `- Re: recognizing SCSI disksPhillip Helbig (undress to reply
`- Re: running VMS on PWS (SRM console)Phillip Helbig (undress to reply

1
Subject: Re: running VMS on PWS (SRM console)
From: Phillip Helbig (undr
Newsgroups: comp.os.vms, comp.sys.dec
Organization: Multivax C&R
Date: Wed, 2 Oct 2019 14:34 UTC
References: 1
Path: i2pn2.org!i2pn.org!aioe.org!.POSTED.Sbr89DxhlAOkM7uG7dyjWQ.user.gioia.aioe.org!not-for-mail
From: hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)
Newsgroups: comp.os.vms,comp.sys.dec
Subject: Re: running VMS on PWS (SRM console)
Date: Wed, 2 Oct 2019 14:34:47 +0000 (UTC)
Organization: Multivax C&R
Lines: 67
Message-ID: <qn2ci7$vrh$1@gioia.aioe.org>
References: <qn26o8$49n$1@gioia.aioe.org>
NNTP-Posting-Host: Sbr89DxhlAOkM7uG7dyjWQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
In article <qn26o8$49n$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

I have some notes on this, and there is some information here and in the
group, but is there a definitive guide?

I understand that a good battery is essential to retain the settings
during a power cycle with longer downtime, and that at least a weak
battery is needed to retain the settings after a brief power cycle after
changing the settings.  However, even if the battery is completely dead,
should it always be possible to make the change (even if one can't save
it)?  In other words, I'd like to verify that the machine is physically
capable of booting from the SRM console before checking the battery
(which implies disassembly).

With no graphic monitor, the console output is on COM1, which is the
lower of the two ports, right?  Is it always visible if there is no
graphics monitor attached, despite any console settings?

I'm pretty sure that I had the SRM console on all three of these at one
time.  Maybe I've forgotten how I got there, maybe something happened
while they were shut down.

I have 8 of these machines altogether, two in my cluster and 6 as
spares.  I did get to to the SRM prompt on the three I mentioned
previously today, but can't do so now.  Three other spares were acquired
more recently and I hadn't checked them out yet.  Checking out one of
the newer ones, I found that, indeed, I can get to the menu to change
the SRM console, but only via a graphics monitor.  F2 works there.  If I
issue a SET CONSOLE SERIAL, then this (and other settings) survive a
power cycle, so I guess that the battery is OK.  (The graphics monitor
didn't work on two of the three in the first group which have a graphics
card.)

Reason: Today, my electricity meter was supposed to be swapped out and,
having no UPS, I powered down the cluster.  As it turned out, the guy
who was to install it was sick and the company didn't call to cancel the
appointment, so it was all unnecessary.  After powering up, one PWS
seems to have died (nothing at the console prompt).  It could be that
the battery is bad and it reverted to the SRM console and graphics
output.  I'll swap in the spare and, if the removed machine otherwise
looks OK, replace the battery and it will become the new spare.

Another glitch: another node came up with the wrong name.  Either the
BOOT_OSFLAGS didn't survive the power cycle, or I had never set them.  I
know that the battery is bad on this machine since it always asks for
the time.  (It is an XP1000, so doesn't have the console issue.)  As,
like today, it is always possible that a machine doesn't survive a power
cycle, I haven't replaced the battery, but will do so when I swap it out
after it fails (perhaps I can get it going again and set it up as a
spare).  Perhaps one can replace the battery while it is running, but
that is physically impossible or at least very difficult on the shelf
where it is located.

Someone (Hoff?) once said that the longer the time between reboots, the
less often one checks one's startup procedures.  Fortunately, mine all
worked, then again, I haven't changed much if anything since the
previous reboot.  Back when patches were availalbe to hobbyists, I used
to reboot regularly (but not power down).  I suppose there is no harm in
a rolling reboot, especially if things are configured so that no shadow
copies will be initiated, and even the occasional cluster reboot, at
least after changing something in the startup.  Powering down the whole
cluster is of course the worst, fortunately it was controlled rather
than just due to the power going off (which I've experienced only a
couple of times in the last forty years).



Subject: Re: running VMS on PWS (SRM console)
From: Phillip Helbig (undr
Newsgroups: comp.os.vms, comp.sys.dec
Organization: Multivax C&R
Date: Wed, 2 Oct 2019 16:16 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!aioe.org!.POSTED.Sbr89DxhlAOkM7uG7dyjWQ.user.gioia.aioe.org!not-for-mail
From: hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)
Newsgroups: comp.os.vms,comp.sys.dec
Subject: Re: running VMS on PWS (SRM console)
Date: Wed, 2 Oct 2019 16:16:13 +0000 (UTC)
Organization: Multivax C&R
Lines: 46
Message-ID: <qn2igd$1ttt$1@gioia.aioe.org>
References: <qn26o8$49n$1@gioia.aioe.org> <qn2ci7$vrh$1@gioia.aioe.org>
NNTP-Posting-Host: Sbr89DxhlAOkM7uG7dyjWQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
In article <qn2ci7$vrh$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

Reason: Today, my electricity meter was supposed to be swapped out and,
having no UPS, I powered down the cluster.  As it turned out, the guy
who was to install it was sick and the company didn't call to cancel the
appointment, so it was all unnecessary.  After powering up, one PWS
seems to have died (nothing at the console prompt).  It could be that
the battery is bad and it reverted to the SRM console and graphics
output.  I'll swap in the spare and, if the removed machine otherwise
looks OK, replace the battery and it will become the new spare.

Well, cluster is back with the original hardware.  :-)

It could have been a lot quicker if I had remembered that the console is
accessible only via a graphics monitor after it reverts to the default
and that, of the three non-satellite machines in the cluster, I actually
have a graphics monitor on the PWS with, as it turned out, the bad
battery.  :-|

But at least I replaced the battery, and learned how to do this.  IIRC,
on the XP1000 the battery can be replaced relatively easy once the cover
is off, but on the PWS one has to remove the mother board ("main logic
board") in order to get to it---which of course means that it can't be
done on a running system.  The other PWS in the cluster is OK.  When I
have time, I'll replace the battery in the XP1000 as well (I believe it
is also a CR2032)---probably when the electricity meter is swapped.  And
the BOOT_OSFLAGS are now set correctly on all machines.  So, in the
current state (with AUTO_ACTION=RESTART), at least the two with good
batteries should come back up if there is an unexpected power cycle.
I'm not sure what happens with regard to asking the time if the battery
is bad: does it give up after a while and boot anyway?  If so, will it
pick up the correct time once in the cluster?

I also learned that not all of my replacement machines are actually
ready to go.  I'll have to check the batteries and graphics cards and
see which machines actually work, or can be made to work.  I might have
to combine a few machines in order to get a smaller number of working
machines.  But now that I know that the motherboard can be removed
easily, perhaps I can just swap them between various PWS.  I have
several different ones, but all "au".  Should there be any problem
swapping the motherboards?  Also, one of the newer (to me) machines
shows DKB0 at the console but, when connected, no disks actually show
up; perhaps a bad graphics card or a loose connection.



Subject: recognizing SCSI disks
From: Phillip Helbig (undr
Newsgroups: comp.os.vms, comp.sys.dec
Organization: Multivax C&R
Date: Thu, 3 Oct 2019 21:56 UTC
References: 1 2 3
Path: i2pn2.org!i2pn.org!aioe.org!.POSTED.DJunE4WseXf+SZxYj1mcJw.user.gioia.aioe.org!not-for-mail
From: hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)
Newsgroups: comp.os.vms,comp.sys.dec
Subject: recognizing SCSI disks
Date: Thu, 3 Oct 2019 21:56:05 +0000 (UTC)
Organization: Multivax C&R
Lines: 43
Message-ID: <qn5qpl$1ckv$1@gioia.aioe.org>
References: <qn26o8$49n$1@gioia.aioe.org> <qn2ci7$vrh$1@gioia.aioe.org> <qn2igd$1ttt$1@gioia.aioe.org>
NNTP-Posting-Host: DJunE4WseXf+SZxYj1mcJw.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
In article <qn2igd$1ttt$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

In article <qn2ci7$vrh$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

Reason: Today, my electricity meter was supposed to be swapped out and,
having no UPS, I powered down the cluster.  As it turned out, the guy
who was to install it was sick and the company didn't call to cancel the
appointment, so it was all unnecessary.  After powering up, one PWS
seems to have died (nothing at the console prompt).  It could be that
the battery is bad and it reverted to the SRM console and graphics
output.  I'll swap in the spare and, if the removed machine otherwise
looks OK, replace the battery and it will become the new spare.

Well, cluster is back with the original hardware.  :-)

Perhaps unrelated to the shutdown and power-off, or perhaps not, a BA356
was making some loud noises.  It didn't sound like a bad disk, but you
never know.  I removed them one by one, but the noise didn't go away.  I
figured it was the fan or something.  So, I swapped the disks into
another box.  This solved the problem, and the node is back in the
cluster now.  Nice to have spare hardware sitting around; thanks to all
who have given me stuff over the years (or, by now, decades).

I've never had a an expansion box itself fail, as opposed to the disks
in it.

As the model was identical, I though that I could just connect it up and
boot, but the console couldn't see the disks.  I power-cycled the
machine (a PWS), and then everything is OK.

Why was it necessary to power-cycle the machine so that it could see the
disks?  I remember once when I pulled a SCSI cable by accident; the
disks (including the system disk )went into mount verification, then
came back when I plugged the cable back in.  That seems much more
dangerous than unplugging the cable at the console prompt.  Of course,
it is a different box (but same connector at the top of the box, the
removable one where the cable plugs in), but surely the SCSI controller
doesn't need the ID of the box (assuming that there is one).



Subject: Re: recognizing SCSI disks
From: Phillip Helbig (undr
Newsgroups: comp.os.vms, comp.sys.dec
Organization: Multivax C&R
Date: Thu, 3 Oct 2019 21:59 UTC
References: 1 2 3 4
Path: i2pn2.org!i2pn.org!aioe.org!.POSTED.DJunE4WseXf+SZxYj1mcJw.user.gioia.aioe.org!not-for-mail
From: hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)
Newsgroups: comp.os.vms,comp.sys.dec
Subject: Re: recognizing SCSI disks
Date: Thu, 3 Oct 2019 21:59:41 +0000 (UTC)
Organization: Multivax C&R
Lines: 33
Message-ID: <qn5r0d$1ct0$1@gioia.aioe.org>
References: <qn26o8$49n$1@gioia.aioe.org> <qn2ci7$vrh$1@gioia.aioe.org> <qn2igd$1ttt$1@gioia.aioe.org> <qn5qpl$1ckv$1@gioia.aioe.org>
NNTP-Posting-Host: DJunE4WseXf+SZxYj1mcJw.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
In article <qn5qpl$1ckv$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

Well, cluster is back with the original hardware.  :-)

Except for the BA356 on one of the nodes.

I've never had a an expansion box itself fail, as opposed to the disks
in it.

As the model was identical, I though that I could just connect it up and
boot, but the console couldn't see the disks.  I power-cycled the
machine (a PWS), and then everything is OK.

Why was it necessary to power-cycle the machine so that it could see the
disks?  I remember once when I pulled a SCSI cable by accident; the
disks (including the system disk )went into mount verification, then
came back when I plugged the cable back in.  That seems much more
dangerous than unplugging the cable at the console prompt.  Of course,
it is a different box (but same connector at the top of the box, the
removable one where the cable plugs in), but surely the SCSI controller
doesn't need the ID of the box (assuming that there is one).

Another puzzle: before shutting down the node to swap the disks, from
another machine I did DISMOUNT/POLICY=MINICOPY on the member of a
three-member shadow set connected to that node.  Now the node is up and
all shadow sets are mounted, and I'm getting a full copy.  Why is that?

When I thought that one of the disks was bad and removed them one by one
to check, I did DISMOUNT/POLICY=MINICOPY and the subsequent mount always
resulted in a minicopy, not a copy.



Subject: Re: recognizing SCSI disks
From: Dave Froble
Newsgroups: comp.os.vms, comp.sys.dec
Organization: A noiseless patient Spider
Date: Fri, 4 Oct 2019 04:14 UTC
References: 1 2 3 4
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: dav...@tsoft-inc.com (Dave Froble)
Newsgroups: comp.os.vms,comp.sys.dec
Subject: Re: recognizing SCSI disks
Date: Fri, 4 Oct 2019 00:14:56 -0400
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <qn6gvd$mvr$1@dont-email.me>
References: <qn26o8$49n$1@gioia.aioe.org> <qn2ci7$vrh$1@gioia.aioe.org>
<qn2igd$1ttt$1@gioia.aioe.org> <qn5qpl$1ckv$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 4 Oct 2019 04:14:37 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="1d1b48b4c5a4badd1443a2dfc2268f08";
logging-data="23547"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/P5MtG+u+2466XpwMxWmcFy5zr36eTu5c="
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:45.0) Gecko/20100101
Thunderbird/45.8.0
Cancel-Lock: sha1:4UPMjHToGSCUA8FRGFzkxTaH06g=
In-Reply-To: <qn5qpl$1ckv$1@gioia.aioe.org>
View all headers
On 10/3/2019 5:56 PM, Phillip Helbig (undress to reply) wrote:

Why was it necessary to power-cycle the machine so that it could see the
disks?  I remember once when I pulled a SCSI cable by accident; the
disks (including the system disk )went into mount verification, then
came back when I plugged the cable back in.  That seems much more
dangerous than unplugging the cable at the console prompt.  Of course,
it is a different box (but same connector at the top of the box, the
removable one where the cable plugs in), but surely the SCSI controller
doesn't need the ID of the box (assuming that there is one).


First, mount verify is something VMS does.  The SRM console does not.

It was not SRM that lost the disks, it most likely was the sCSI controller.  As Hans mentioned, the SCSI controller needed to be commanded to go explore the SCSI bus.


--
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486


Subject: Re: recognizing SCSI disks
From: Phillip Helbig (undr
Newsgroups: comp.os.vms, comp.sys.dec
Organization: Multivax C&R
Date: Sat, 12 Oct 2019 18:12 UTC
References: 1 2 3 4 5
Path: i2pn2.org!i2pn.org!aioe.org!.POSTED.StpzdGPsafTzD/uCTWDY5Q.user.gioia.aioe.org!not-for-mail
From: hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)
Newsgroups: comp.os.vms,comp.sys.dec
Subject: Re: recognizing SCSI disks
Date: Sat, 12 Oct 2019 18:12:18 +0000 (UTC)
Organization: Multivax C&R
Lines: 26
Message-ID: <qnt522$1ad1$2@gioia.aioe.org>
References: <qn26o8$49n$1@gioia.aioe.org> <qn2ci7$vrh$1@gioia.aioe.org> <qn2igd$1ttt$1@gioia.aioe.org> <qn5qpl$1ckv$1@gioia.aioe.org> <qn6gvd$mvr$1@dont-email.me>
NNTP-Posting-Host: StpzdGPsafTzD/uCTWDY5Q.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
In article <qn6gvd$mvr$1@dont-email.me>, Dave Froble
<davef@tsoft-inc.com> writes:

On 10/3/2019 5:56 PM, Phillip Helbig (undress to reply) wrote:

Why was it necessary to power-cycle the machine so that it could see the
disks?  I remember once when I pulled a SCSI cable by accident; the
disks (including the system disk )went into mount verification, then
came back when I plugged the cable back in.  That seems much more
dangerous than unplugging the cable at the console prompt.  Of course,
it is a different box (but same connector at the top of the box, the
removable one where the cable plugs in), but surely the SCSI controller
doesn't need the ID of the box (assuming that there is one).


First, mount verify is something VMS does.  The SRM console does not.

Right.

It was not SRM that lost the disks, it most likely was the sCSI
controller.  As Hans mentioned, the SCSI controller needed to be
commanded to go explore the SCSI bus.

I was thinking that SHOW DEV would do that, but perhaps SHOW CONFIG is
needed.



Subject: running VMS on PWS (SRM console)
From: Phillip Helbig (undr
Newsgroups: comp.os.vms, comp.sys.dec
Organization: Multivax C&R
Date: Wed, 2 Oct 2019 12:55 UTC
Path: i2pn2.org!i2pn.org!aioe.org!.POSTED.Sbr89DxhlAOkM7uG7dyjWQ.user.gioia.aioe.org!not-for-mail
From: hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)
Newsgroups: comp.os.vms,comp.sys.dec
Subject: running VMS on PWS (SRM console)
Date: Wed, 2 Oct 2019 12:55:37 +0000 (UTC)
Organization: Multivax C&R
Lines: 32
Message-ID: <qn26o8$49n$1@gioia.aioe.org>
NNTP-Posting-Host: Sbr89DxhlAOkM7uG7dyjWQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
I have some notes on this, and there is some information here and in the
group, but is there a definitive guide?

I understand that a good battery is essential to retain the settings
during a power cycle with longer downtime, and that at least a weak
battery is needed to retain the settings after a brief power cycle after
changing the settings.  However, even if the battery is completely dead,
should it always be possible to make the change (even if one can't save
it)?  In other words, I'd like to verify that the machine is physically
capable of booting from the SRM console before checking the battery
(which implies disassembly).

With no graphic monitor, the console output is on COM1, which is the
lower of the two ports, right?  Is it always visible if there is no
graphics monitor attached, despite any console settings?

Testing three machines today, one doesn't show anything after the power
cycle (though I think that it did at one time), one says "Please select
the operating system to start:" but appears to offer only winnt.  At the
"Press Enter to choose:" prompt, it says that the selection is invalid.

One machine gets to "F2: setup", but pressing F2 does nothing.

The console is a VT with the standard settings for use as console on a
VMS system.  Should it be possible to switch to the SRM console with
such a console terminal attached?  Or do I need a graphics monitor
and/or PC-style keyboard?

I'm pretty sure that I had the SRM console on all three of these at one
time.  Maybe I've forgotten how I got there, maybe something happened
while they were shut down.



Subject: Re: running VMS on PWS (SRM console)
From: Phillip Helbig (undr
Newsgroups: comp.os.vms, comp.sys.dec
Organization: Multivax C&R
Date: Wed, 2 Oct 2019 13:58 UTC
References: 1
Path: i2pn2.org!i2pn.org!aioe.org!.POSTED.Sbr89DxhlAOkM7uG7dyjWQ.user.gioia.aioe.org!not-for-mail
From: hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply)
Newsgroups: comp.os.vms,comp.sys.dec
Subject: Re: running VMS on PWS (SRM console)
Date: Wed, 2 Oct 2019 13:58:15 +0000 (UTC)
Organization: Multivax C&R
Lines: 18
Message-ID: <qn2adm$l4a$1@gioia.aioe.org>
References: <qn26o8$49n$1@gioia.aioe.org>
NNTP-Posting-Host: Sbr89DxhlAOkM7uG7dyjWQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
In article <qn26o8$49n$1@gioia.aioe.org>,
helbig@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

I understand that a good battery is essential to retain the settings
during a power cycle with longer downtime, and that at least a weak
battery is needed to retain the settings after a brief power cycle after
changing the settings.  However, even if the battery is completely dead,
should it always be possible to make the change (even if one can't save
it)?  In other words, I'd like to verify that the machine is physically
capable of booting from the SRM console before checking the battery
(which implies disassembly).

So these settings are lost when there is no power, and also the date and
time since the TOY clock isn't running.  What about other console
variables such as AUTO_ACTION and BOOTDEF_DEV?  Do they survive a lack
of power on all models?



1
rocksolid light 0.7.2
clearneti2ptor