While I was travelling, power went off for a few hours for 
maintenance.  (This is the first time I have ever experienced planned 
outage and only the second or third unplanned.)  I thought about logging 
in and shutting everything down cleanly, but decided to use it as a hard 
test instead.  Two of three nodes came back up; that was expected since 
the battery in one of the PWS is dead (now I know which one).  Can this 
be replaced by a standard off-the-shelf battery?  Everything else came 
up OK, but I am puzzled by this:

   13-MAR-2012 17:35:38.00 MINNIM 13-MAR-2012 17:38:31.84
   13-MAR-2012 14:46:40.00 JANDER 13-MAR-2012 17:38:59.19

These two lines are generated by the following code:

   $    OPEN/APPEND/SHARE BOOT_HISTORY CLUSTER_MANAGER:BOOT.HISTORY
   $    WRITE BOOT_HISTORY "''F$GETSYI("BOOTTIME")' ''NODENAME' ''F$TIME()"
   $    CLOSE BOOT_HISTORY

The three minutes for MINNIM between booting and writing to the file is
about what I expect.  JANDER waited for MINNIM to boot (quorum is 2), so 
that explains the almost three-hour wait between booting and writing for 
JANDER, but why did MINNIM boot almost three hours after JANDER?  All 
the nodes lost power at the same time.

Relevant system parameters seem to be:

   SHADOW_MBR_TMO                300
   MVTIMEOUT                    3600
   SHADOW_SYS_WAIT               480
   RECNXINTERVAL                  20

all of which are much shorter than three hours.

On Saturday, March 24, 2012 7:35:57 AM UTC-4, Phillip Helbig---undress to reply wrote:
> While I was travelling, power went off for a few hours for 
> maintenance.
>
>    13-MAR-2012 17:35:38.00 MINNIM 13-MAR-2012 17:38:31.84
>    13-MAR-2012 14:46:40.00 JANDER 13-MAR-2012 17:38:59.19
> 
> The three minutes for MINNIM between booting and writing to the file is
> about what I expect.  JANDER waited for MINNIM to boot (quorum is 2), so 
> that explains the almost three-hour wait between booting and writing for 
> JANDER, but why did MINNIM boot almost three hours after JANDER?  All 
> the nodes lost power at the same time.
> 

What do I win if I guess correctly?

Power failed around 14:46.

Jander crashed when quorum was lost, but its battery backup survived the entire (approximately) three hour outage. Therefore, it rebooted immediately and then went into a wait until quorum could be regained.

Minnim had no battery backup and crashed hard (and cold).

Power was restored around 17:35.

Minnim reboots.  Quorum is restored.  Due to variability in getting through the startup procedure Minnim writes the "I'm alive" message before Jander does.  I'm speculating that a third node in the cluster may have been responsible for part of the delay.

FrankS wrote:

> Jander crashed when quorum was lost, but its battery backup survived the entire (approximately) three hour outage


It is my understanding that a node does not crash when quorum is lost.
It simply freezes.

It is when connection is restored to other node(s) that a decision is
made on who should commit harikiri to ensure there is only one lock
database in the cluster which can be propagated to virgin nodes.


If Jander remained powered throughout the power failure, was the only
node to remain powered AND had access to its system disk dirung that
time, there would have been no reason for it to reboot, and even less to
show a boot time of the start of power failure.

Perhpas there was an unclean transfer from mains to battery which caused
jander to reboot at the time the power failure occured, at which point
it would wait for quorum until some other node would join.

In article
<27617031.3022.1332623951163.JavaMail.geo-discussion-forums@vbtv42>,
FrankS <sapienza@noesys.com> writes: 

> >    13-MAR-2012 17:35:38.00 MINNIM 13-MAR-2012 17:38:31.84
> >    13-MAR-2012 14:46:40.00 JANDER 13-MAR-2012 17:38:59.19
> > 
> > The three minutes for MINNIM between booting and writing to the file is
> > about what I expect.  JANDER waited for MINNIM to boot (quorum is 2), so 
> > that explains the almost three-hour wait between booting and writing for 
> > JANDER, but why did MINNIM boot almost three hours after JANDER?  All 
> > the nodes lost power at the same time.
> 
> What do I win if I guess correctly?

Eternal fame in comp.os.vms.

> Power failed around 14:46.
> 
> Jander crashed when quorum was lost, but its battery backup survived
> the entire (approximately) three hour outage. Therefore, it rebooted
> immediately and then went into a wait until quorum could be regained. 
> 
> Minnim had no battery backup and crashed hard (and cold).
> 
> Power was restored around 17:35.
> 
> Minnim reboots.  Quorum is restored.  Due to variability in getting
> through the startup procedure Minnim writes the "I'm alive" message
> before Jander does.  I'm speculating that a third node in the cluster
> may have been responsible for part of the delay.

Interesting theory, but not correct in my case.  Power went off about
12:45 and came back about 14:45.  Thus, the reboot time for JANDER
reflects power coming back on.  Also, I'm pretty sure the battery is
just to keep the TOY clock and possibly the console settings.  (JANDER
is an XP1000; perhaps the console settings can survive without a battery
here, but not the TOY clock.  The other two are PWS and definitely need
a battery for the console settings since without one they forget they
are supposed to boot VMS.  The third system, a PWS, is the one with the
bad battery since it didn't come back up at all until I set up the
console for VMS again when I returned.)  I don't think I've ever had a 
system with batteries to enable it to survive power going off (that 
would be a UPS, presumably).  (I think there were also some systems with 
batteries to keep the contents of RAM without power, hence the 
distinction between RESTART and REBOOT, but I don't think I've ever had 
such a system either.)

So, it looks like that when power came back, JANDER rebooted immediately 
but MINNIM did not.  I'm not sure what time, exactly, is BOOTTIME in the 
startup sequence, but it is pretty early.  I don't see what could have 
changed after almost 3 hours to cause MINNIM to boot.  One difference, 
of course, is that JANDER perhaps re-formed the cluster whereas MINNIM 
re-joined the cluster.  However, any differences in behaviour here (such 
as waiting for served disks on other nodes to become available so that 
they can be mounted in a shadow set) should lead to much smaller delays.

Phillip Helbig---undress to reply wrote:

> Interesting theory, but not correct in my case.  Power went off about
> 12:45 and came back about 14:45.

So now you give us a different story...


> just to keep the TOY clock and possibly the console settings.  (JANDER

Ok, so the mention of battery was misleading. You're just talking ahout
the toy clock, not some system that can remain powered on (or memory
kept alive) via batteries.


Of one has a bad TOY battery, then the VMS system may have been asking
for time before proceeding with the boot. And it may have taken you that
long to enter the time. (or perhpaps the propt for time times out after
a couple hours and VMS boots anyways)


> of course, is that JANDER perhaps re-formed the cluster whereas MINNIM 
> re-joined the cluster.

After a power failure, your cluster no longer exists. None, nada. It is
recreated from scratch.

First one to boot will create a new instance of the cluster with quorum
numbers coming from sysgen data. Then other nodes will attempt to join
that cluster.



Is it possible that you have a bad system disk on one node and it took
that long to perform the equivalent of mount/verify of the system disk ?

In article <4f6f763f$0$1653$c3e8da3$f017e9df@news.astraweb.com>, JF
Mezei <jfmezei.spamnot@vaxination.ca> writes: 

> Ok, so the mention of battery was misleading. You're just talking ahout
> the toy clock, not some system that can remain powered on (or memory
> kept alive) via batteries.

Right.

> Of one has a bad TOY battery, then the VMS system may have been asking
> for time before proceeding with the boot. And it may have taken you that
> long to enter the time. (or perhpaps the propt for time times out after
> a couple hours and VMS boots anyways)

No-one entered any time (except for the THIRD system, not mentioned in
the post, which as expected didn't boot because it forgot it was
supposed to boot VMS because the battery was dead, and for the same
reason the time had to be entered); the system booted by itself.
According to the documentation, the value of 65535 �fortnights causes
the prompt to repeat indefinitely:

Parameter Name            Current    Default    Minimum    Maximum Unit  Dynamic
--------------            -------    -------    -------    ------- ----  -------
TIMEPROMPTWAIT              65535         -1          0         -1 uFortnights

       o  If TIMEPROMPTWAIT is a number in the range of 32768 through
          65535, the prompt for the time is issued at intervals starting
          with 2 and doubling until 256 seconds is reached. If no
          response is received, the prompts restart, with the 2-second
          interval. This prompting process repeats indefinitely, until
          you specify a time.

> Is it possible that you have a bad system disk on one node and it took
> that long to perform the equivalent of mount/verify of the system disk ?

Maybe.  Any way to easily test this?

On Mar 26, 6:21=A0am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> In article <4f6f763f$0$1653$c3e8da3$f017e...@news.astraweb.com>, JF
>
> Mezei <jfmezei.spam...@vaxination.ca> writes:
> > Ok, so the mention of battery was misleading. You're just talking ahout
> > the toy clock, not some system that can remain powered on (or memory
> > kept alive) via batteries.
>
> Right.
>
> > Of one has a bad TOY battery, then the VMS system may have been asking
> > for time before proceeding with the boot. And it may have taken you tha=
t
> > long to enter the time. (or perhpaps the propt for time times out after
> > a couple hours and VMS boots anyways)
>
> No-one entered any time (except for the THIRD system, not mentioned in
> the post, which as expected didn't boot because it forgot it was
> supposed to boot VMS because the battery was dead, and for the same
> reason the time had to be entered); the system booted by itself.
> According to the documentation, the value of 65535 =B5fortnights causes
> the prompt to repeat indefinitely:
>
> Parameter Name =A0 =A0 =A0 =A0 =A0 =A0Current =A0 =A0Default =A0 =A0Minim=
um =A0 =A0Maximum Unit =A0Dynamic
> -------------- =A0 =A0 =A0 =A0 =A0 =A0------- =A0 =A0------- =A0 =A0-----=
-- =A0 =A0------- ---- =A0-------
> TIMEPROMPTWAIT =A0 =A0 =A0 =A0 =A0 =A0 =A065535 =A0 =A0 =A0 =A0 -1 =A0 =
=A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 -1 uFortnights
>
> =A0 =A0 =A0 =A0o =A0If TIMEPROMPTWAIT is a number in the range of 32768 t=
hrough
> =A0 =A0 =A0 =A0 =A0 65535, the prompt for the time is issued at intervals=
 starting
> =A0 =A0 =A0 =A0 =A0 with 2 and doubling until 256 seconds is reached. If =
no
> =A0 =A0 =A0 =A0 =A0 response is received, the prompts restart, with the 2=
-second
> =A0 =A0 =A0 =A0 =A0 interval. This prompting process repeats indefinitely=
, until
> =A0 =A0 =A0 =A0 =A0 you specify a time.
>
> > Is it possible that you have a bad system disk on one node and it took
> > that long to perform the equivalent of mount/verify of the system disk =
?
>
> Maybe. =A0Any way to easily test this?

Would it be safe to assume that you've disabled the operator logs on
these systems? If you hadn't, they might have provided some clues as
to what went on when.

On Saturday, March 24, 2012 4:35:57 AM UTC-7, Phillip Helbig---undress to reply wrote:
> While I was travelling, power went off for a few hours for 
> maintenance.  (This is the first time I have ever experienced planned 
> outage and only the second or third unplanned.)  I thought about logging 
> in and shutting everything down cleanly, but decided to use it as a hard 
> test instead.  Two of three nodes came back up; that was expected since 
> the battery in one of the PWS is dead (now I know which one).  Can this 
> be replaced by a standard off-the-shelf battery?  
 ...

The battery in a PWS is very easy to replace.  Look in the c.o.v archives
from about 3 years ago when I asked the question.  The battery is a standard
CRxxxx (where I can't recall the "xxxx" at the moment, but it's something
like "2013").   Hoff might have instructions on his web site as well.

   -Ken

In article <12194534.75.1332777111132.JavaMail.geo-discussion-forums@ynjl17>, Ken Fairfield <ken.fairfield@gmail.com> writes:
>On Saturday, March 24, 2012 4:35:57 AM UTC-7, Phillip Helbig---undress to reply wrote:
>> While I was travelling, power went off for a few hours for 
>> maintenance.  (This is the first time I have ever experienced planned 
>> outage and only the second or third unplanned.)  I thought about logging 
>> in and shutting everything down cleanly, but decided to use it as a hard 
>> test instead.  Two of three nodes came back up; that was expected since 
>> the battery in one of the PWS is dead (now I know which one).  Can this 
>> be replaced by a standard off-the-shelf battery?  
> ...
>
>The battery in a PWS is very easy to replace.  Look in the c.o.v archives
>from about 3 years ago when I asked the question.  The battery is a standard
>CRxxxx (where I can't recall the "xxxx" at the moment, but it's something
>like "2013").   Hoff might have instructions on his web site as well.

2032.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

In article
<009d3b8b-dd40-44ab-b19d-d40f7f8f1091@z31g2000vbt.googlegroups.com>,
John Wallace <johnwallace4@yahoo.co.uk> writes: 

> Would it be safe to assume that you've disabled the operator logs on
> these systems? If you hadn't, they might have provided some clues as
> to what went on when.

No, I have operator logs.  Both start at the time the second node boots:

DISK$USER:[SYSTEM.MANAGER]OPERATOR_JANDER.LOG;30


%%%%%%%%%%%  OPCOM  13-MAR-2012 17:39:35.52  %%%%%%%%%%%
Logfile has been initialized by operator _JANDER$OPA0:
Logfile is JANDER::DISK$USER:[SYSTEM.MANAGER]OPERATOR_JANDER.LOG;30

%%%%%%%%%%%  OPCOM  13-MAR-2012 17:39:35.52  %%%%%%%%%%%
Operator status for operator JANDER::DISK$USER:[SYSTEM.MANAGER]OPERATOR_JANDER.LOG;30
CENTRAL, PRINTER, TAPES, DISKS, DEVICES, CARDS, NETWORK, CLUSTER, SECURITY,
LICENSE, OPER1, OPER2, OPER3, OPER4, OPER5, OPER6, OPER7, OPER8, OPER9, OPER10,
OPER11, OPER12

%%%%%%%%%%%  OPCOM  13-MAR-2012 17:39:35.52  %%%%%%%%%%%
OPCOM on JANDER is initializing the local node JANDER, csid 00010002, system 113
4

%%%%%%%%%%%  OPCOM  13-MAR-2012 17:39:35.52  %%%%%%%%%%%
OPCOM on JANDER recognizes node MINNIM, csid 00010001, system 1094
Attempting to establish communications, placing node in STARTING state.

%%%%%%%%%%%  OPCOM  13-MAR-2012 17:39:35.52  %%%%%%%%%%%

As you can see, the operator log files are not on the system disk, but
on a three-member shadow set (each member with a direct connection to 
one of the three nodes).  Normally, when some members are not available, 
the shadow set is formed with those which are (I don't have 
/POLICY=REQUIRE_MEMBERS).  No information here on what was going on.

Phillip Helbig---undress to reply wrote:

> No, I have operator logs.  Both start at the time the second node boots:
> 
> DISK$USER:[SYSTEM.MANAGER]OPERATOR_JANDER.LOG;30


Yes because the operator log is written to only once OPCOM starts.
Cluster formation and waiting for quorum messages are sent to OPA0: but
not logged to operator.log because they happen well before the boot
proceeds to where operator.log is written to.

I believe that the error log is perhaps the first log file to see any
messages after booting begins.

"Phillip Helbig---undress to reply"  wrote in message=20
news:jkkbit$a98$1@online.de...
>
>While I was travelling, power went off for a few hours for
>maintenance.  (This is the first time I have ever experienced planned
>outage and only the second or third unplanned.)  I thought about =
logging
>in and shutting everything down cleanly, but decided to use it as a =
hard
>test instead.  Two of three nodes came back up; that was expected since
>the battery in one of the PWS is dead (now I know which one).  Can this
>be replaced by a standard off-the-shelf battery?  Everything else came
>up OK, but I am puzzled by this:
>
>   13-MAR-2012 17:35:38.00 MINNIM 13-MAR-2012 17:38:31.84
>   13-MAR-2012 14:46:40.00 JANDER 13-MAR-2012 17:38:59.19
>
>These two lines are generated by the following code:
>
>   $    OPEN/APPEND/SHARE BOOT_HISTORY CLUSTER_MANAGER:BOOT.HISTORY
>   $    WRITE BOOT_HISTORY "''F$GETSYI("BOOTTIME")' ''NODENAME' =
''F$TIME()"
>   $    CLOSE BOOT_HISTORY
>
>The three minutes for MINNIM between booting and writing to the file is
>about what I expect.  JANDER waited for MINNIM to boot (quorum is 2), =
so
>that explains the almost three-hour wait between booting and writing =
for
>JANDER, but why did MINNIM boot almost three hours after JANDER?  All
>the nodes lost power at the same time.
>
>Relevant system parameters seem to be:
>
>   SHADOW_MBR_TMO                300
>   MVTIMEOUT                    3600
>   SHADOW_SYS_WAIT               480
>   RECNXINTERVAL                  20
>
>all of which are much shorter than three hours.

There is not much information, so I can only guess. A possible scenario =
is=20
that at 14:46 the power returned. Both systems started, but MINNIM has a =

problem with autonegotiation, because the network switch is also =
booting. No=20
good communication could be established between the two nodes. They both =

start to wait for quorum. At 17:35, for some reason (a power glitch?) =
MINNIM=20
crashed and rebooted again. Now there was no problem with =
autonegotiation,=20
the communication was restored, quorum was found and the cluster was =
formed.=20

On my apha, one of he IDE drives started to fail. Mounting it would take
hours in mount verification.

If this happens to the system disk, then it is likely that the boot
would be delayed.

Try ANA/DISK/REPAIR on the system drive to see how long it takes and if
it finds problems.

Failing this, you need to power down that node and boot it back and this
time, look at the output from OPA0 to see about any error messages or
problems during the early boot that would be indicative of a disk problem.

IDE disks do not log errors. So SHOW ERROR is not an indication of
health of the disk.

On Mon, 26 Mar 2012 18:51:18 -0400, JF Mezei wrote:

> Phillip Helbig---undress to reply wrote:
> 
>> No, I have operator logs.  Both start at the time the second node
>> boots:
>> 
>> DISK$USER:[SYSTEM.MANAGER]OPERATOR_JANDER.LOG;30
> 
> 
> Yes because the operator log is written to only once OPCOM starts.
> Cluster formation and waiting for quorum messages are sent to OPA0: but
> not logged to operator.log because they happen well before the boot
> proceeds to where operator.log is written to.
> 
> I believe that the error log is perhaps the first log file to see any
> messages after booting begins.

You can log the execution of STARTUP.COM to STARTUP.LOG with the correct 
SYSMAN STARTUP incantations (or via the SYSGEN STARTUP_P2 parameter).



-- 
Paul Sture

In article <rpo849-fm3.ln1@news.sture.ch>, Paul Sture <paul@sture.ch>
writes: 

> You can log the execution of STARTUP.COM to STARTUP.LOG with the correct 
> SYSMAN STARTUP incantations (or via the SYSGEN STARTUP_P2 parameter).

Right.  I've never bothered with this.  Is there any reason NOT to 
define it?  If so, what do people recommend?  "D"?

On 27/03/12 21:43, Phillip Helbig---undress to reply wrote:
> In article<rpo849-fm3.ln1@news.sture.ch>, Paul Sture<paul@sture.ch>
> writes:
>
>> You can log the execution of STARTUP.COM to STARTUP.LOG with the correct
>> SYSMAN STARTUP incantations (or via the SYSGEN STARTUP_P2 parameter).
>
> Right.  I've never bothered with this.  Is there any reason NOT to
> define it?  If so, what do people recommend?  "D"?
>
IIRC I've used "VD". Also: remember to purge STARTUP.LOG periodically, 
especially if you frequently reboot.

-- 
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/php/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before

In article <lb7a49-kge.ln1@Ubuntu.mike-r.com>, Henry Crun <mike@rechtman.com> writes:
>On 27/03/12 21:43, Phillip Helbig---undress to reply wrote:
>> In article<rpo849-fm3.ln1@news.sture.ch>, Paul Sture<paul@sture.ch>
>> writes:
>>
>>> You can log the execution of STARTUP.COM to STARTUP.LOG with the correct
>>> SYSMAN STARTUP incantations (or via the SYSGEN STARTUP_P2 parameter).
>>
>> Right.  I've never bothered with this.  Is there any reason NOT to
>> define it?  If so, what do people recommend?  "D"?
>>
>IIRC I've used "VD". Also: remember to purge STARTUP.LOG periodically, 
>especially if you frequently reboot.

I user "VDC" -- I remember it as "Vdc" (Volts Direct Current)

Your options are:

$if f$locate("V",p2) .nes. f$length(p2) then stdrv$verify = stdrv$true
$if f$locate("D",p2) .nes. f$length(p2) then stdrv$log = stdrv$true
$if f$locate("C",p2) .nes. f$length(p2) then stdrv$verbose = stdrv$true
$if f$locate("P",p2) .nes. f$length(p2) then stdrv$comp_verify = stdrv$true

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

On Wed, 28 Mar 2012 12:04:19 +0000, VAXman- wrote:

> In article <lb7a49-kge.ln1@Ubuntu.mike-r.com>, Henry Crun
> <mike@rechtman.com> writes:
>>On 27/03/12 21:43, Phillip Helbig---undress to reply wrote:
>>> In article<rpo849-fm3.ln1@news.sture.ch>, Paul Sture<paul@sture.ch>
>>> writes:
>>>
>>>> You can log the execution of STARTUP.COM to STARTUP.LOG with the
>>>> correct SYSMAN STARTUP incantations (or via the SYSGEN STARTUP_P2
>>>> parameter).
>>>
>>> Right.  I've never bothered with this.  Is there any reason NOT to
>>> define it?  If so, what do people recommend?  "D"?
>>>
>>IIRC I've used "VD". Also: remember to purge STARTUP.LOG periodically,
>>especially if you frequently reboot.
> 
> I user "VDC" -- I remember it as "Vdc" (Volts Direct Current)
> 
> Your options are:
> 
> $if f$locate("V",p2) .nes. f$length(p2) then stdrv$verify = stdrv$true
> $if f$locate("D",p2) .nes. f$length(p2) then stdrv$log = stdrv$true $if
> f$locate("C",p2) .nes. f$length(p2) then stdrv$verbose = stdrv$true $if
> f$locate("P",p2) .nes. f$length(p2) then stdrv$comp_verify = stdrv$true

Yes, and "VDC" is what the SYSMAN command sets it to:

SYSMAN> STARTUP SET OPTIONS/VERIFY=FULL/OUTPUT=FILE/CHECKPOINTING
SYSGEN> USE CURRENT
SYSGEN>  SHOW STARTUP_P2
Parameter Name    Current
--------------    -------
STARTUP_P2         "VDC "

At startup you then see this on the console:

%STDRV-I-STARTUP, OpenVMS startup begun at 28-MAR-2012 22:09:45.08
%STDRV-I-LOG, startup output is being written to SYS$SYSTEM:STARTUP.LOG

However, SYSMAN is not recommended, for after an AUTOGEN, the setting 
reverts:

$ mc sysgen show startup_p2
Parameter Name    Current
--------------    -------
STARTUP_P2         "    "
$

So you should put 

STARTUP_P2="VDC"

into your MODPARAMS.DAT to ensure it sticks.

-- 
Paul Sture

In article <jl06ot$cv4$1@dont-email.me>, David Froble <davef@tsoft-inc.com> writes:
>Paul Sture wrote:
>> On Wed, 28 Mar 2012 12:04:19 +0000, VAXman- wrote:
>> 
>>> In article <lb7a49-kge.ln1@Ubuntu.mike-r.com>, Henry Crun
>>> <mike@rechtman.com> writes:
>>>> On 27/03/12 21:43, Phillip Helbig---undress to reply wrote:
>>>>> In article<rpo849-fm3.ln1@news.sture.ch>, Paul Sture<paul@sture.ch>
>>>>> writes:
>>>>>
>>>>>> You can log the execution of STARTUP.COM to STARTUP.LOG with the
>>>>>> correct SYSMAN STARTUP incantations (or via the SYSGEN STARTUP_P2
>>>>>> parameter).
>>>>> Right.  I've never bothered with this.  Is there any reason NOT to
>>>>> define it?  If so, what do people recommend?  "D"?
>>>>>
>>>> IIRC I've used "VD". Also: remember to purge STARTUP.LOG periodically,
>>>> especially if you frequently reboot.
>>> I user "VDC" -- I remember it as "Vdc" (Volts Direct Current)
>>>
>>> Your options are:
>>>
>>> $if f$locate("V",p2) .nes. f$length(p2) then stdrv$verify = stdrv$true
>>> $if f$locate("D",p2) .nes. f$length(p2) then stdrv$log = stdrv$true $if
>>> f$locate("C",p2) .nes. f$length(p2) then stdrv$verbose = stdrv$true $if
>>> f$locate("P",p2) .nes. f$length(p2) then stdrv$comp_verify = stdrv$true
>> 
>> Yes, and "VDC" is what the SYSMAN command sets it to:
>> 
>> SYSMAN> STARTUP SET OPTIONS/VERIFY=FULL/OUTPUT=FILE/CHECKPOINTING
>> SYSGEN> USE CURRENT
>> SYSGEN>  SHOW STARTUP_P2
>> Parameter Name    Current
>> --------------    -------
>> STARTUP_P2         "VDC "
>> 
>> At startup you then see this on the console:
>> 
>> %STDRV-I-STARTUP, OpenVMS startup begun at 28-MAR-2012 22:09:45.08
>> %STDRV-I-LOG, startup output is being written to SYS$SYSTEM:STARTUP.LOG
>> 
>> However, SYSMAN is not recommended, for after an AUTOGEN, the setting 
>> reverts:
>> 
>> $ mc sysgen show startup_p2
>> Parameter Name    Current
>> --------------    -------
>> STARTUP_P2         "    "
>> $
>> 
>> So you should put 
>> 
>> STARTUP_P2="VDC"
>> 
>> into your MODPARAMS.DAT to ensure it sticks.
>> 
>
>Any permanent changes to parameters should be in modparams.dat
>
>If it ain't in modparams, it never happened ....

OMG!  I just looked for the Apollo moon landings in MODPARAMS.DAT and
it's not there! :)

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

Gettinng "Startup.com" to log to file is fine, but you still don't log
the output that is produced prior to startup being called, and it is
this input which would be important in cases where the computer is
waiting for quorum, waiting for date/time, or issuing messages about a
bad disk requiring rebuilding etc.

Only logging of OPA0: to another computer does the trick.

VAXman- @SendSpamHere.ORG wrote:

>>If it ain't in modparams, it never happened ....
> 
> OMG!  I just looked for the Apollo moon landings in MODPARAMS.DAT and
> it's not there! :)
> 


I just checked mine.  Neither Elvis nor Michael Jackson are dead. They
must stll be alive :-)

JF Mezei wrote:
> VAXman- @SendSpamHere.ORG wrote:
> 
>>> If it ain't in modparams, it never happened ....
>> OMG!  I just looked for the Apollo moon landings in MODPARAMS.DAT and
>> it's not there! :)
>>
> 
> 
> I just checked mine.  Neither Elvis nor Michael Jackson are dead. They
> must stll be alive :-)

You guys are out of date.  All of that, and more, is in mine ....  :D

On Thu, 29 Mar 2012 01:17:45 +0000, VAXman- wrote:

> In article <jl06ot$cv4$1@dont-email.me>, David Froble
> <davef@tsoft-inc.com> writes:
>>
>>Any permanent changes to parameters should be in modparams.dat
>>
>>If it ain't in modparams, it never happened ....
> 
> OMG!  I just looked for the Apollo moon landings in MODPARAMS.DAT and
> it's not there! :)

I have comes across some incontrovertible proof on that subject :-)

http://stuffucanuse.com/fake_moon_landings/moon_landings.htm





-- 
Paul Sture

In article <gcjd49-nnq.ln1@news.sture.ch>, Paul Sture <paul@sture.ch> writes:
>On Thu, 29 Mar 2012 01:17:45 +0000, VAXman- wrote:
>
>> In article <jl06ot$cv4$1@dont-email.me>, David Froble
>> <davef@tsoft-inc.com> writes:
>>>
>>>Any permanent changes to parameters should be in modparams.dat
>>>
>>>If it ain't in modparams, it never happened ....
>> 
>> OMG!  I just looked for the Apollo moon landings in MODPARAMS.DAT and
>> it's not there! :)
>
>I have comes across some incontrovertible proof on that subject :-)
>
>http://stuffucanuse.com/fake_moon_landings/moon_landings.htm

:)

FYI, I actually know *the* Neil Armstrong's son and his granddaughter.
My comments here WRT the moon landings were for humor.  I am convinced
that all the "Capricorn One"-like conspiracies are specious!

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

On Thu, 29 Mar 2012 13:07:55 +0000, VAXman- wrote:

> In article <gcjd49-nnq.ln1@news.sture.ch>, Paul Sture <paul@sture.ch>
> writes:
>>On Thu, 29 Mar 2012 01:17:45 +0000, VAXman- wrote:
>>
>>> In article <jl06ot$cv4$1@dont-email.me>, David Froble
>>> <davef@tsoft-inc.com> writes:
>>>>
>>>>Any permanent changes to parameters should be in modparams.dat
>>>>
>>>>If it ain't in modparams, it never happened ....
>>> 
>>> OMG!  I just looked for the Apollo moon landings in MODPARAMS.DAT and
>>> it's not there! :)
>>
>>I have comes across some incontrovertible proof on that subject :-)
>>
>>http://stuffucanuse.com/fake_moon_landings/moon_landings.htm
> 
> :)
> 
> FYI, I actually know *the* Neil Armstrong's son and his granddaughter.
> My comments here WRT the moon landings were for humor.  I am convinced
> that all the "Capricorn One"-like conspiracies are specious!

Understood.  I actually enjoy a *good* conspiracy theory in the same way 
I enjoy a decent spy thriller, i.e. as an intellectual "what if?" 
exercise.

-- 
Paul Sture

On 2012-03-29 03.23, JF Mezei wrote:
> VAXman- @SendSpamHere.ORG wrote:
>
>>> If it ain't in modparams, it never happened ....
>>
>> OMG!  I just looked for the Apollo moon landings in MODPARAMS.DAT and
>> it's not there! :)
>>
>
>
> I just checked mine.  Neither Elvis nor Michael Jackson are dead. They
> must stll be alive :-)

Were they born? Maybe they never existed, except in your imagination. :-)

	Johnny

JF Mezei mentioned  on 29-3-2012 3:18:
> Gettinng "Startup.com" to log to file is fine, but you still don't log
> the output that is produced prior to startup being called, and it is
> this input which would be important in cases where the computer is
> waiting for quorum, waiting for date/time, or issuing messages about a
> bad disk requiring rebuilding etc.
>
> Only logging of OPA0: to another computer does the trick.

In the early stages, a lot can be learned from modifying the boot flag 
(adding 0x20000 to the normal value for your node produces *a lot* of 
output)

But this, also, on the physical console only.

/Wilm

On Fri, 30 Mar 2012 09:40:06 +0200, Wilm Boerhout wrote:

> JF Mezei mentioned  on 29-3-2012 3:18:
>> Gettinng "Startup.com" to log to file is fine, but you still don't log
>> the output that is produced prior to startup being called, and it is
>> this input which would be important in cases where the computer is
>> waiting for quorum, waiting for date/time, or issuing messages about a
>> bad disk requiring rebuilding etc.
>>
>> Only logging of OPA0: to another computer does the trick.
> 
> In the early stages, a lot can be learned from modifying the boot flag
> (adding 0x20000 to the normal value for your node produces *a lot* of
> output)
> 
> But this, also, on the physical console only.
> 

It's worth mentioning here that TDi Technologies have Hobbyist licenses 
for their ConsoleWorks product:

http://www.openvms.org/stories.php?story=11/12/13/9332146

-- 
Paul Sture

In article <00ABF10B.82CC2FD9@SendSpamHere.ORG>, VAXman- 
@SendSpamHere.ORG writes: 

> FYI, I actually know *the* Neil Armstrong's son and his granddaughter.
> My comments here WRT the moon landings were for humor.  I am convinced
> that all the "Capricorn One"-like conspiracies are specious!

Don't believe conspiracy theories.  They are just a means to divert 
people from the Real Truth.

It's not true, but still funny---the story about Mr. Gorsky.

On Sun, 01 Apr 2012 09:56:06 +0000, Phillip Helbig---undress to reply
wrote:

> In article <00ABF10B.82CC2FD9@SendSpamHere.ORG>, VAXman-
> @SendSpamHere.ORG writes:
> 
>> FYI, I actually know *the* Neil Armstrong's son and his granddaughter.
>> My comments here WRT the moon landings were for humor.  I am convinced
>> that all the "Capricorn One"-like conspiracies are specious!
> 
> Don't believe conspiracy theories.  They are just a means to divert
> people from the Real Truth.
> 
> It's not true, but still funny---the story about Mr. Gorsky.

I'd forgotten about that one.

http://asmalldoseofreality.bloghi.com/2006/06



-- 
Paul Sture