[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference mvblab::alphaserver_4100

Title:AlphaServer 4100
Moderator:MOVMON::DAVISS
Created:Tue Apr 16 1996
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:648
Total number of notes:3158

455.0. "BOOTDEF_DEV ignored on REBOOT" by VIVIAN::D_BONO () Fri Jan 31 1997 11:57

    
    Hello,
    
    I have a customer that has a problem with BOOTDEF_DEV and its operation
    with SYS$SHUTDOWN REBOOT on his Alphaserver 4100.
    
    The customers normal boot disk is DKB0 hence BOOTDEF_DEV is DKB0 
    They also boot another disk to perform some jobs (DKB100)
    Once these jobs have completed on DKB100 the system performs a 
    SYS$SHUTDOWN with a reboot.
    
    The reboot however boots to DKB100 again ignoring BOOTDEF_DEV.
    
    This is an issue for the customer as all his VAX's and other Alpha's
    boot off the disk defined by BOOTDEF_DEV. This was not the case
    originally with the VAX7000 and the Firmware had to be modified. (IPMT
    log No CFS_33671 see also Note 1069 in the LASER conference.)
    
    I guess there are cases where customers want this the other way around.
    
    Is there an environment variable that changes this behaviour or some 
    kind of workaround?
    
    Thanks,
    
    Dave Bono (MCS London)
    
T.RTitleUserPersonal
Name
DateLines
455.1The customer experienced expected console behaviorLANDO::CUMMINSFri Jan 31 1997 14:3611
    This is expected behavior. All AlphaServer platforms implement reboots
    this way. A reboot from the booted devcie is attempted. BOOTDEF_DEV is
    used on cold boots, shutdown halt followed by boot, etc.
    
    If the customer wishes to boot off an alternate device and then boot
    off the default (BOOTDEF_DEV) device, he/she should shutdown halt and
    then boot. The impact is that the user must wait until the shutdown is
    complete.
    
    No changes to console are planned for this problem. The design is
    architected to handle the 99% case versus the 1% case.
455.2OpenVMS support for VAX-style reboots on AlphaHARMNY::CUMMINSWed May 07 1997 16:14168
    A lot happened since this original note and my reply were posted.
    
    Suffice it to say that we worked out a solution to Reuter's issue with
    VMS reboots that involved using existing SRM console support to modify
    environment variables via UNIX/VMS callbacks coupled with a VMS program
    developed explicitly for Reuters to modify boot params at console level
    using these callbacks. The program is unofficially available for other
    VMS/Rawhide customers that may want it. It has not been qualified on
    any other Alpha platform, but should work fine provided the platform's
    SRM console SETENV and SAVENV console callbacks work properly.
    
    Attached, you will find some mail between Engineering and the Reuter's
    account team along the way to the final implementation/solution.
    
    
From:	HARMNY::CUMMINS      "Bill Cummins, PKO3-2/Q21, 223-4641"  4-MAR-1997 16:53:15.56
To:	@DIS$:REUTERS
CC:	CUMMINS
Subj:	Reuters and OpenVMS reboots on AlphaServers

Hello Sue,

The OpenVMS development group has come up with a way to provide support
for Reuters to get their desired reboot behavior on AlphaServers. The
same basic support exists today (though not officially documented) under
UNIX.

Can you tell me whether your contacts at Reuters feel this would be an
acceptable solution? See mail attachments from OpenVMS development group.

Am hoping Reuters and your account team will take this solution and run
with it (with support from OpenVMS, MCS, etc.) I'm afraid any console-
based change to suit Reuters' needs would:

  * Fly in the face of the reason the Digital UNIX, OpenVMS, and SRM
    console development groups added the ability to manipulate console
    environment variables (EVs) from a running operating system in the
    first place. In other words, it would be a hack that would violate /
    work around the Alpha SRM.

  * Not offer maximum flexibility. With a change as implemented on the
    DEC 7000 platform (addition of DEC7000-specific console EV called
    BOOTVAX_COMPAT, one gets either VAX-style or Alpha-style reboots,
    but not both unless the behavior is known a priori before booting.

  * Be slow in coming (FW release cycles) and piece-meal as far as
    platform/firmware support is concerned.

Let me know what you think.

Best regards,
BC

Distribution:

nm%chefs::christophers		!Emma
nm%chefs::menasche		!Andrea
nm%chefs::gledhill_s		!Sue
nm%chefs::corfas		!Avi
nm%vivian::d_bono		!Dave
nm%chefs::mangan_s		!Steve
nm%wimpey::caulfield_m		!Mike
!Richard Baly
nm%thundr::lipcon		!Jesse

From:	STAR::JANETOS      "VMS Engineering - ZKO3-4/U14 - 381x1532" 26-FEB-1997 15:10:51.99
To:	MAY30::CUMMINS
CC:	JHUBER, KFOLLIEN, KLEINSORGE, JANETOS
Subj:	RE: Just read my voicemail; after seeing your mail..

Bill,

There seems to be general agreement that this approach to the Reuters
reboot problem is reasonable.

What we need to know is if Reuters will go along with it.  We are not
issuing any "patch" -- we are sort of acting like software services
and providing a utility program to the system manager.

Reuters would have to modify their shutdown procedure to call the new
program prior to shutdown/reboot.  Could you sound out Sue Gledhill on
whether this approach is acceptable to Reuters?

Fred -- is there a generally accepted way to cause a program to be
invoked during shutdown?  Do we tell them to edit shutdown.com to call
this program?  This is something we need to test here.

- Jim J.

==============================================================

From:	MAY30::CUMMINS      "Bill Cummins, PKO3-2/Q21, 223-4641" 26-FEB-1997 13:45:37.36
To:	STAR::JANETOS
CC:	
Subj:	Just read my voicemail; after seeing your mail..

Let me know what Hanley et al say.

You know my opinion. I'd rather it be a VMS-wide solution versus a hack
that would become official over time in the console (new platforms
anyway..) Especially considering that more recent versions of UNIX support
callbacks, though I'm not sure BOOT_DEV and BOOTDEF_DEV have been tested..

If you'd prefer being in the loop on mail to Sue Gledhill, no problem here.
Else, if you want me to send her mail and CC you when you've gotten VMS
feedback, that's fine as well. Let me know.

BC

From:	STAR::JANETOS "VMS Engineering - ZKO3-4/U14 - 381x1532  26-Feb-1997 1258 -0500" 26-FEB-1997 12:58:00.22
To:	HARMNY::CUMMINS
CC:	JANETOS
Subj:	Bill -- our current thoughts on Reuters/reboot

From:	19584::HIGGINS "Ron Higgins, OpenVMS Kernel Mgr, 381-0007  26-Feb-1997 1147 -0500" 26-FEB-1997 11:47:36.80
To:	HANLEY
CC:	JANETOS
Subj:	A: Bill, any opinions?

From:	STAR::JANETOS      "VMS Engineering - ZKO3-4/U14 - 381x1532" 26-FEB-1997 10:58:27.87
To:	HIGGINS
CC:	JHUBER, KLEINSORGE, KFOLLIEN,JANETOS
Subj:	Reuters reboot problem

Ron,

We have talked briefly about the Reuters reboot problem.  I would like
to fill you in on this and get your opinion on how to proceed.

The problem is that Reuters wants VAX style behaviour in how console
environment variables are used to define the default boot device.  On
VAX, on a shutdown/reboot, the system is unconditionally booted from
the default boot device.  On Alpha, on a shutdown/reboot, the system
is rebooted from the previous boot device (not necessarily the default
boot device).

The Alpha behaviour is the architecturally correct behaviour.  Reuters
originally requested that the RAwhide console be modified to work VAX
style.  As we worked with the console developers, we determined that
we could write a simple program to restore the default boot device. 
Reuters could add this program to the shutdown path, and the effect
would be to give them VAX behaviour on Alpha.  This seemed to be a
better solution than a console hack that would fix the problem on
Rawhide only.

My thinking on this was to give the program source code to the MCS
people that support Reuters.  The conditions are

1) this is a programming example that demonstrates how to manipulate
(read/write) console environment variables.  You need CMKRNL privilege
to run it.  This program restores the BOOTDEF_DEV environment variable
(default boot device) to the value contained in BOOT_DEV (the last
device from which a succcessful boot has been accomplished).  The
program has not been exhaustively tested.  You are free to modify it
to suit your specific environment

2) we will check the example into SYS$EXAMPLES in V7.2 (or maybe
V7.1-maintenance)

MCS can then work with Reuters to implement a solution to their reboot
problem.  We support MCS as necessary until Reuters is happy.

We still have some things we need to do -- more testing and code
review, and a discussion with the MCS/Reuters people.  

Does this approach sound reasonable to you?

- Jim J.
455.3Mail from VMSHARMNY::CUMMINSWed May 07 1997 16:1536
From:	STAR::JANETOS "VMS Engineering - ZKO3-4/U14 - 381x1532  21-Mar-1997 1516 -0500" 21-MAR-1997 15:24:43.53
To:	VIVIAN::D_BONO
CC:	JHUBER,KLEINSORGE,HIGGINS,HANLEY,KFOLLIEN,HARMNY::CUMMINS,JANETOS
Subj:	Reuters -- program to restore default boot device environment variable

Dave --

I am about to mail you the program that we believe gives Reuters the
desired behaviour of auto-reboots occuring from the default boot
device.  We have tested it on Rawhide and verified that we do indeed
copy BOOTDEF_DEV (the default boot device list) to BOOT_DEV (device
list used on all boot attempts that are not initiated by a BOOT
command).

You say:

    $ run default_boot
    $ reboot

and the reboot will occur using the device list in BOOTDEF_DEV.  This
should give Reuters the behaviour they desire -- that shutdown/reboot
invoked from VMS results in a reboot using the device list in BOOTDEF_DEV.

Full documentation on the program is contained in the module header
(its a simple program -- 121 lines of C).

Let me know how the testing goes with Reuters, or if you have any
questions.  Also let me know how you want to proceed -- if you would
like us to check the code into SYS$EXAMPLES.

I will mail you the source code and a build file.

Regards,

- Jim Janetos
OpenVMS Systems Group
455.4Contact Jim Janetos in OpenVMS development group for programHARMNY::CUMMINSWed May 07 1997 16:1835
From:	STAR::JANETOS      "VMS Engineering - ZKO3-4/U14 - 381x1532"  7-MAY-1997 14:54:57.74
To:	HARMNY::CUMMINS
CC:	JANETOS
Subj:	RE: Do you mind me posting this mail and a couple earlier mails
from me to Sue Gledhill & Co. as a reply to ALPHASERVER_4100 note 455.*

Bill, we never decided whether to check it in.  For now, if someone
asks, send them to me.  We may decide to stick it in SYS$EXAMPLES for
V7.2, but that won't be available until q3/q4 98.

- JJ
    
From:   HARMNY::CUMMINS      "Bill Cummins, PKO3-2/Q21, 223-4641"
To:     STAR::JANETOS
CC:     CUMMINS
Subj:   RE: Do you mind me posting this mail and a couple earlier mails
from me to Sue Gledhill & Co. as a reply to ALPHASERVER_4100 note 455.*

Good news. Thanks, BC

Who should I tell noters to contact if they want the program? or will it
be rolled into VMS programming examples or something similar in a future
release?

From:   STAR::JANETOS      "VMS Engineering - ZKO3-4/U14 - 381x1532" 7-MAY-1997 14:49:17.53
To:     HARMNY::CUMMINS
CC:     JANETOS
Subj:   RE: Do you mind me posting this mail and a couple earlier mails
from me to Sue Gledhill & Co. as a reply to ALPHASERVER_4100 note 455.*


No problem Bill.  Fyi, I heard from them -- they have made some mode
(mods) to the program I sent them, they seem happy, and are trying to
figure out exactly how they want to integrate the program into their
environment.
455.5can be available next month, rather than next year... :-)XDELTA::HOFFMANSteve, OpenVMS EngineeringMon May 12 1997 18:025
   I'd suspect this program might be useful to other customers, and I can
   get it available to customers _well_ before it ships in Q4CY1998 (that
   was quoted here), via DIGITAL's web site.  (We've been putting a few
   other useful tools there.)