webes problem with Sys$Sysroot

[Rich Hearn]

Hi All,

My WEBES "expired" back in March. I'm running 4.4.3 on vms8.3 on a 2 node ES47 cluster. I was able to do Option 6 on Node 2, but it didn't work on Node1 so I looked and saw that Desta wasn't running there; I attempted to start it with the same error. This not only worked on Node2, but also worked on my 2 Node Test Cluster (DS20's v8.3/v7.3-2)


CACHE1::DISK$INFSYS:[RJHEARN]_>show log sys$sysroot
"SYS$SYSROOT" = "DSA1:[SYS1.]" (LNM$SYSTEM_TABLE)
= "SYS$COMMON:"
1 "SYS$COMMON" = "DSA1:[SYS1.SYSCOMMON.]" (LNM$SYSTEM_TABLE)
CACHE1::DISK$INFSYS:[RJHEARN]_>


CACHE1::DISK$INFSYS:[RJHEARN]_>
CACHE1::DISK$INFSYS:[RJHEARN]_>@ dsa1:[vms$common.hp.svctools.common.bin]webes_install

The WEBES V0404-3 Kit is not found at DISK$INFSYS:[RJHEARN].
Please ensure that the Kit exist at the specified path.


WEBES UPDATE - MAIN MENU
========================

1. SEA Menu
2. CCAT Menu
3. Start At Boot Time
4. Customer Information
5. System Information
6. Service Obligation
7. Start DESTA Director
8. Stop DESTA Director
9. Uninstall Webes
- Fully uninstalls Webes and all installed dependent components
such as SEA and CCAT
10. Exit
=========================


Usage: Only one option from the above choices
for example: 4 or 6 or 10

Choice Selection : 7

%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\SYS$SYSROOT\



WEBES UPDATE - MAIN MENU
========================

1. SEA Menu
2. CCAT Menu
3. Start At Boot Time
4. Customer Information
5. System Information
6. Service Obligation
7. Start DESTA Director
8. Stop DESTA Director
9. Uninstall Webes
- Fully uninstalls Webes and all installed dependent components
such as SEA and CCAT
10. Exit
=========================


Usage: Only one option from the above choices
for example: 4 or 6 or 10

Choice Selection :


Any ideas as to what I might be "missing" here?

Thanks,
Rich

[marsh_1]

hi,

have you compared the svctools_home logical on these systems ?
what happens if you try outside the menu e.g desta start or desta servob override at a command prompt ?

[Hoff]

If you're inclined to dig around into this, turn on DCL verification and find out where the WEBES stuff went off the rails. Probably an (untested?) error path.

The usual annual-renewal command is:

$ DESTA SERVOB CHANGE

I'd probably try that, then a manual product (re)start, and then (if it's still stuck) reboot the box, then the cluster.

[Rich Hearn]

1st of all, thank you to both of you for the responses.

Mark,

I have re-checked them and they are appropriate (ie: SYS1 on Node1 SYS2 on Node2 - yes, I'm aware it's non-standard :^)

Same error with DESTA SERVOB CHANGE on the cmd line.


Hoff,

I've turned on vfy and here's what shows:


$ DESTA SERVOB SHOW
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\SYS$SYSROOT\
$ INQUIRE Good " Do you want to change the Webes Service Obligation?[NO]"
Do you want to change the Webes Service Obligation?[NO]: no

I'm guessing that "something" in DESTA_CMD.EXE(?) can't locate the logical. Perhaps an un-install is in order (re-booting anything is next to impossible). I may go that route to see what happens.

Tnx agn,
Rich

[Hoff]

Based on the error messages, It appears that the tool is probably spawning a subprocess and running some DCL. (Based on what I've seen with the service tools here, this approach appears fairly likely.)

If you have the cycles, then you could use SET WATCH /CLASS=ALL FILES (and then /CLASS=NONE) to see any direct accesses from within the tool, but I'd guess the only way you're going to spot this is via file access security auditing (probably via enabling the successful access auditing; which you probably don't want to have enabled for very long).

Flip one of these two on, issue the DESTA SERVOB SHOW directly, then flip it off. The former shows to the screen, the latter requires you go look in the security audit logs.

Once you find the DCL command procedure file, you can take a look at the DCL code there, and continue the debug.

Or you can punt on this whole self-maintenance approach and call up HP support and see if they know what's going on here and can sort this out for you. (It does look like there's a bug here in WBEM/WEBES/WWWHATEVER, regardless.)

[Rich Hearn]

Hoff,

I may have stumbled onto the answer - or at least an indication. I thought I'd try for the un-install and it wanted to do the "other" node also. Now I had been MSCP sharing each nodes system disk (they're separate, also a common disk *is* shared between systems) and a few days ago, I stopped sharing them. I thought I had each WEBES set up to be on it's own DSA - I'm wondering if somehow it's "cluster installed" (for lack of a better term) and not sharing them is causing my initial error.

Since we have a contract with HP I could call, but I like to try to understand as much as I can before I go off and do that - correct it if possible is even nicer :^)

Thanks for the additional thoughts tho'

Rich
_