Re: Shutting down Oracle under VMS
Date: 1996/03/12
Message-ID: <1996Mar11.183800.1_at_sldb4.slac.stanford.edu>#1/1
In article <1996Mar11.114907_at_alpha.vitro.com>,
vaxs09_at_alpha.vitro.com (John Briggs, VAX system manager, x4411) writes:
> In article <1996Mar10.173751.1_at_sldb4.slac.stanford.edu>,
> fairfield_at_sldb4.slac.stanford.edu writes:
> ...
>> $ Run /Detached - >> /Authorize - >> /Uic=ORACLE >> /Process_Name=ORA_SHUTDOWN - >> /Input=dev:[dir]ORA_SHUTDOWN.COM - >> /Output=dev:[dir]ORA_SHUTDOWN.LOG
>
> There are multiple problems with this.
>
> First, you don't specify an image to run. Let's assume that you meant
> to run SYS$SYSTEM:LOGINOUT.EXE.
Did I really leave that off? Geez...sorry 'bout that. Really, I _was_ running LOGINOUT for all my tests. ;-p
> Given that, the above command still _will not_ create a detached process
> running under the [ORACLE] UIC.
A typo, corrected in an immediate follow-up.
> The problem is that with the /AUTHORIZE switch specified, LOGINOUT will
> implicitly use the username of the submitter as a key into the system
> authorization file and will look up the UIC and various quotas there.
>
> If you turn off the /AUTHORIZE switch, you can create a detached process
> running as [ORACLE], but the USERNAME on that process will still be the
> the submitter's USERNAME. If that was your intent, you might just as
> well have done a SET UIC [ORACLE] and skipped the detached process
> entirely. And, according to the problem description, SET UIC by itself
> didn't work.
This is the more serious problem. I hadn't checked carefully enough for the username of the created process. I've just verified the affect of /AUTHORIZE versus (the default) /NOAUTHORIZE. It's true that /AUTHORIZE does, among other things, override the /UIC specified. [I remember this in the dim recesses of my mind, but I wasn't looking for that at the time I did my tests.] And /UIC is not sufficient to get the process created under the USERNAME of the uic specified. :-(
> The standard solutions for this are to either detach a process from
> a batch job (inapplicable in the environment at hand) or to use some
> kernel mode code to change the username of the current process in
> CTL$T_USERNAME and/or JIB$T_USERNAME, detach the process and then restore
> the original username.
There are at least two SETUSER programs available for VAX (I think dating back to a very early DECUS submission if I read the source comments correctly, like VMS 2.x or so), and there is at least one version for Alpha (which I received from the author but haven't exercised so I can't say whether it's robust or not). Using SETUSER ORACLE on VAX hardware, followed by RUN /DETACHED, has the desired affect in conjunction with /AUTH (whereas with /NOAUTH, the detached process inherits the current process' privileges, etc.).
In any case, some other follow-ups have suggested granting the appropriate identifier to the SYSTEM account, which certainly seems like the simplest and most straight forward solution.
Other follow-ups in this thread have claimed they manage to submit batch jobs during SYSHUTDWN (to shutdown Oracle). I'd be interested in the contents of the .LOG file from such a job. My reading of SYS$SYSTEM:SHUTDOWN.COM (OVMS 6.1), and observation of the shutdown sequence, is that all queues (and the queue manager if it is running on the current node) are stopped 1 to 2 minutes _prior_ to running SYSHUTDWN.COM. Therefore, I can't see how you could successfully submit and execute the Oracle shutdown from a batch job. What am I missing here?
-Ken
-- Kenneth H. Fairfield | Internet: Fairfield_at_Slac.Stanford.Edu SLAC, P.O.Box 4349, MS 46 | DECnet: 45537::FAIRFIELD (45537=SLACVX) Stanford, CA 94309 | Voice: 415-926-2924 FAX: 415-926-3515 ------------------------------------------------------------------------- These opinions are mine, not SLAC's, Stanford's, nor the DOE's...Received on Tue Mar 12 1996 - 00:00:00 CET