Minimal bootup for Alpha and VAX

[Santhosh_5]

dear All,

Pls let me know how to do the minimal bootup on Alpha, [ DIGITAL TCP/IP Services for OpenVMS Alpha Version V4.2 - ECO 1 on a AlphaServer 4100 5/400 4MB running OpenVMS V7.1-2] and MicroVAX [ DIGITAL TCP/IP Services for OpenVMS VAX Version V4.2 on a MicroVAX 3100-95 running OpenVMS V6.2].

Pls let me know the command procedure for the same.

Thanks in advance.

[Himanshu_3]

Hi Santhosh,

Before Everybody starts replying, I would advise you to please assign points to the group memebers who have taken out time to answer to our questions. I have seen your past questions and you havent assigned points to any of the answers. So please do so as a thanksgiving gesture to all those who spare their time and knwledge for you .

I would post the answer for this shortly.

Regards,
Himanshu

[Santhosh_5]

I am sorry, I am new bee. henceforth definetly i will do that.

Expecting CONVERSATIONAL BOOTSTARP command procedure for minimal bootup for alpha 4000 and mvax servers.

[Himanshu_3 · Accepted solution]

Ok no probs Santhosh,

Now for the conversational boot you will have to give the following commands

>>> boot -fl 0,1

You will get the sysboot prompt where you do...

SYSBOOT> USE DEFAULT
SYSBOOT> SET STARTUP_P1 "MIN"
SYSBOOT> CONTINUE

When the system finishes booting, determine which changed parameter caused the problem, and reset the parameter value. If you specified the value for the parameter in the AUTOGEN parameter file MODPARAMS.DAT, fix the value in that file and run AUTOGEN

Example:
SYSBOOT> USE DEFAULT

SYSBOOT> SET STARTUP_P1 "MIN"
SYSBOOT> CONTINUE
Username: SYSTEM
Password:

$ EDIT SYS$SYSTEM:MODPARAMS.DAT
.
$ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT

Hope this helps Santhosh,
Regards,
HP

[Kris Clippeleyr]

Santhosh,

See also this thread http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=702895 for a conversational boot on a VAX.
The conversational boot on an Alpha is already explained.
The sequence of SYSBOOT> commands mentioned are the same for a VAX.

Greetz,

Kris

[Moderator edit: The above link is no longer valid.]

[Bojan Nemec]

Hi,

For the VAX the boot command is:
>>> boot /r5:1
or just
>>> boot /1

And just follow HP instructions for the alpha.
I will recomend another thing. The system will remember the STATRUP_P1 "MIN", so the system will boot minimal next time. You can set

SYSBOOT> SET WRITESYSPARAMS 0

to not write the parameters or remember to set
SYSGEN> SET STATRUP_P1 "".

Bojan

[Santhosh_5]

Dear All,

Thanks for your information. I would like to change the system time for summer to winter time change. i have to set back the time one hour when we have booted minimal. Then we have to wait for one hour before restarting the servers. This is to prevent double time entries in the Oracle databases.

One more ?; shall i do the above procedure through CA console connect. because we are mainitainig the alpha and vax servers from remotely. any suggestions.

[Santhosh_5]

I am sorry, CA console management

[Bojan Nemec]

I dont know CA console management, but I supose that it connects directly yo the console port. If it is so thats only a problem of "trusting" the communication between yours and remote place. You never knows what could happen, so its better to have a live person backup.


Now, when I know the reason for minimal boot the SYSBOOT> procedure will be:

SYSBOOT> SET STARTUP_P1 "MIN"
SYSBOOT> SET WRITESYSPARAMS 0
SYSBOOT> CONTINUE


Bojan

[Santhosh_5]

Hi BoJAN,

How to clear minimal parameters, is it through SYSGEN..

SYSGEN> SET STARTUP_P1 ""
SYSGEN> USE PARAMETERS CURRENT
SYSGEN> WRITE PARAMETERS CURRENT
SYSGEN> CONTINUE

thanks,

[Bojan Nemec]

Hi,

The sysgen sequence is:

$ MCR SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET STARTUP_P1 ""
SYSGEN> WRITE CURRENT
SYSGEN> EXIT

CONTINUE is a sysboot command and is not used in sysgen.

Bojan

[Santhosh_5]

SYSBOOT> SET WRITESYSPARAMS 0

What it do does mean, any thing need to do on SYSGEN.

[Santhosh_5]

Dear All, So the sequence for Alpha and Micro VAX is as follows,

For Alpha,

>>> boot -fl 0,1

will get the sysboot prompt where you do...

SYSBOOT> USE DEFAULT
SYSBOOT> SET STARTUP_P1 "MIN"
SYSBOOT> SET WRITESYSPARAMS 0
SYSBOOT> CONTINUE

Username: SYSTEM or equivalent
Password:

For VAX,

The minimal boot command is:

>>> boot /r5:1
or just
>>> boot /1

SYSBOOT> USE DEFAULT
SYSBOOT> SET STARTUP_P1 "MIN"
SYSBOOT> SET WRITESYSPARAMS 0
SYSBOOT> CONTINUE
Username: SYSTEM or equivalent
Password:

Now the servers are in conversational mode after successfully completed the above sequence, wait for some time then execute the below said commands to clear the SYSBOOT sequences,

The SYSGEN sequence is:

$ MCR SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET STARTUP_P1 ""
SYSGEN> WRITE CURRENT
SYSGEN> EXIT


Hope this will resove my problem. Pls let me know any thing I missed.

[Himanshu_3]

Hey Santhosh,

You do not need to minimal boot your system for changing the timings. As per your prvious listings, whatever the versions you are running , you can change the timings on them by modifying

SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM

DAYLIGHT_SAVINGS.COM allows you to perform either of the following actions:

*Make the changes immediately. (Usually, however, you would use UTC$TIME_SETUP.COM to make changes immediately by answering Yes to Question 5)

*Queue a batch job to make the changes at a future time. (This is the most common use of this command procedure.)

For more information you can follow the below link:

http://h71000.www7.hp.com/doc/731FINAL/6017/6017pro_018.html

Ciao,
HP

[Moderator edit: Removed the broken link. Please refer to https://support.hpe.com/]

[Bojan Nemec]

Hi,

The
SYSBOOT> USE DEFAULT
line is not necesary. If you use
SYSBOOT> SET WRITESYSPARAMS 0
you dont need the sysgen sequence or better do:

$ MCR SYSGEN
SYSGEN> SHOW STARTUP_P1

and if is not set to "" do the

SYSGEN> USE CURRENT
SYSGEN> SET STARTUP_P1 ""
SYSGEN> WRITE CURRENT

sequence.

Bojan

[Santhosh_5]

Hi Ciao, Hp,

I am plannin g to this activity on Db servers and real time servers which is generating reports by second basis. if i am not doing the minimal, then the application and db willbe created double entry. We have to set back the time one hour when we have booted minimal. Then we have to wait for one hour before restarting the servers. This is to prevent double time entries in the Oracle databases.

[Lawrence Czlapinski]

In our 24X7X365 environment, we aren't allowed to use a time change as a reason to shutdown our nodes.
1. We submit the time change via batch on each node. [SYSMAN can be used to run the submit procedure on an entire cluster].
SET PROC/PRIV=SYSPRV
SYSMAN
SYSMAN> DO @submit_procedure.com
SYSMAN> exit
2. Our Oracle DBAs are responsible for shutting down Oracle (and other applications that would have a time change problem), so:
A. Our other users are unaffected by the time change. The DBA are also responsible for starting Oracle back up after the time change and verifying that is running correctly. So unless one of our systems has problems with the time change, the system admins aren't involved.
B. Our Oracle users are only down between the time Oracle is shutdown and Oracle is brought back up.
3. ALTERNATIVE 1 (Only shutdown Oracle): Instead of shutting down our systems, we have our DBA's submit an oracle shutdown procedure. If it is a forward time change, the DBA's can schedule a batch job to submit the oracle startup procedure to run after the time change. If it is a backward time change, the oracle startup procedure can be submitted or run manually.
This has the advantage that we can continue to use our other applications and production continues to run.
4. ALTERNATIVE 2 (Modified normal boot without starting Oracle):
An alternative, would be to do a reboot utilizing a SYSGEN STARTUP_Px (where x is 2-8) to not startup the Oracle application and/or other applications.
In SYSTARTUP_VMS.COM, you can put in lines like:
$ if (f$edit(f$getsyi("STARTUP_P8"),"TRIM")).eqs. "" then ora_disk:[dir]oracle_startup.com
or:
$ if (f$edit(f$getsyi("STARTUP_P8"),"TRIM")).eqs. ""
$ then
$! oracle_startup logic
...
$ endif
$! The following type of startup can be useful if you want a regular boot but only a partial or special type of startup.
In SYSTARTUP_VMS.COM, you can put in lines like:
$! TIMC - is for time change
$ if (f$edit(f$getsyi("STARTUP_P8"),"TRIM")) .eqs. "TIMC") then exit
After the time change, you can run the Oracle startup procedure.
Lawrence

[Lawrence Czlapinski]

For easier testing, you could also copy lines to a procedure:
$! STARTUP_TIME_CHANGE.COM
$! STARTUP_P8 = "TIMC" ! uncomment to test
$ STARTUP_P8 ! or other name
$ STARTUP_P8 = (f$edit(f$getsyi("STARTUP_P8"),"TRIM"))
$ IF STARTUP_P8 .eqs. "TIMC") then exit
Or copy part of line and add a write to sys$output to verify the syntax:
$ if f$edit(f$getsyi("STARUP_P8"),"TRIM")) then write sys$output "success"
Lawrence

[Jan van den Ende]

Santhosh,

I absolutely have to agree with Lawrence, if nothing else then for the principle:
If ORACLE (or an Ora application) cannot stand the time change, then WHY should anything NOT Oracle (including VMS itself) have to shutdown?
Just shutting down Oracle DB will get what you need, and anything that has no issues with the DST change should not be bothered.

Lawrence, :-)
what do you mean by ".. our 24X7X365 .." ?
Why are you specifying some 7-year interval?

( OTOH, I ve seen this quite often, but is IS a contamination of "7*24", meaning "full week", (and usually NOT holiday-weeks etc), and 24*365", meaning "whole year" (well, strictly speaking, leaving on average 6 jours per year, or a leap-day every 4 years)
Denoting TRUE never-down is sometimes written as "7 * 365.25"
(and you should READ this with a smiley, but nevertheless, the basis for this is VERY serious)

Cheers.

Have one on me.

Jan

[Lokesh_2]

Hi Santosh,

The above boot command for conversation boot is fine if your system root number is 0. If this is not the case the you have to change your boot command accordingly.

For ALPHA,
boot -fl n,1

For VAX,

boot /R5:n0000001

where n is your system root number.


For more details follow the instructions for performing a conversational boot in one of the following manuals:
On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.
On Alpha systems, refer to the HP OpenVMS Alpha Version 7.3-2 Upgrade and Installation Manual

HTH,
Thanks & regards,
Lokesh

[Lawrence Czlapinski]

Jan, sorry about that, I meant 24X7 with as little downtime as possible. Usually downtime is because of a hardware or network problem. Occasionally, we upgrade OS, when we are down for a maintenance window. We don't quite reach 24X365.25 on all of our production machines. Our production machines are usually up over 365 days out of every 365.25 which is over .9993.
Lawrence

[Jan van den Ende]

Lawrence,
that sure is not too bad, is it?

Compare:

I once attended a "technical" session on high uptime for a bank's (IBM) computer.
It was announced as "how to get to 100% uptime."
During the lecture it turned out it was intended to mean:

(drumsolo growing to crescendo)

... always running between 7:30 am & 20:00 pm on weekdays, !!!!!
and just about the hardest effort they made was Database shutdown & backup, and "DAYLY" IPL (IBM parlance for reboot) in scheduled off-hours shifts, and arranging for maintenance to be done, not on weekdays but on weekends.
And most people in the audience had systems more or less comparable to yours!

Well, the Q&A turned out a little embarassing, and a concensus on the advice NEVER to call such system uptimes 100% in a VMS audience..

Maybe a lot of the effect is in the eye of the beholder.

fwiw,


Cheers.

Have one on me.

Jan

[Martin P.J. Zinser]

Hi,

well back to the topic of time changes ;-),
you might want to consult the FAQ at

http://h71000.www7.hp.com/wizard/faq/vmsfaq_004.html#time8

in particular section 4.3.2. This might be to late to implement for this Sunday, but spring will be here soon again

Drifting the time has its own issues (esp. if you need to synch your time with external applications records), but might beat shutting down the system/app completely.

Greetings, Martin

[Moderator edit: Removed the broken link. Please refer to https://support.hpe.com/]

[Lawrence Czlapinski]

Martin,
"For those areas which switch between daylight savings time (DST) and standard time, the [NTP] time value is not drifted. The time is adjusted by the entire interval. This procedure is inherent in the definition of the switch between DST and standard time."
That is why, NTP is stopped before a time change and restarted after.
http://h71000.www7.hp.com/wizard/faq/vmsfaq_004.html#time8
Lawrence

[Moderator edit: Removed the broken link. Please refer to https://support.hpe.com/]

[Santhosh_5]

Thanks every body,

the acitivity has been successfully completed. Once again thanks for your co-operation and time.