having issues with executing the new RMU commands

[ronh1107]

I am having issues executing the new RMU commands that I now need to executed. Please review the following command that I am attempting to perform that are causing issues. It appears that I am not establishing the logical PROD_DB. When I execute this command it reports that the transaction does not translate.

(5:08 PM) tsloat: NRCAVA::Theresa's:::>RMU/SHOW CORRUPT_PAGES PROD_DB
%RMU-W-BADDBNAME, can't find database root RMADSK05:[APPL.SLOAT.DB]PROD_DB.RDB;
-RMS-E-FNF, file not found
%RMU-F-CANTOPNROO, cannot open root file "PROD_DB"
%RMU-F-FTL_SHOW, Fatal error for SHOW operation at 29-MAY-2010 16:04:51.68



NRCAVA::Theresa's:::>@ALI_DBA_HOME:DBA
%DCL-E-OPENIN, error opening ALI_DBA_HOME:[APPL.SLOAT.DB]DBA.COM; as input
-RMS-F-DEV, error in device name or inappropriate device type for operation



5:32 PM) Sanjeev: $ sh log prod_db
"PROD_DB" = "PROD_DB_DISK1:[NRCTANDEM]PROD_DB.RDB" (LNM$PROCESS_TABLE)

NRCAVA::Theresa's:::>sh log prod_db
%SHOW-S-NOTRAN, no translation for logical name PROD_DB


Please note that I have done nothing different to my login.com script.

Since the UAF changes were performed I was able to execute the following SQL commands & they executed within 5 minutes. Yesterday & today this same SQL script does not complete & has taken over 45 minutes before I CTL Y to leave.

Directory RMADSK05:[APPL.SLOAT.DB]

[Hoff]

Quite a few folks here in ITRC are having issues supporting this same cluster.

Still running that ancient version of OpenVMS Alpha V7.2-2 on a SAN cluster?

That version has very early SAN support, so it's not the most stable of configurations.

At its simplest, check the LOGIN.COM and SYLOGIN.COM processing for Sanjeev, and see if there's a DCL procedure invoked that defines these logical names. Turn on verification (SET VERIFY) and then invoke the procedures and see if you can locate where the PROD_DB logical name is defined.

The last time something similar to this case arose on this cluster, Riverhawk was pointed to the MOUNT command and related, and that looks similar to this case. This probably isn't the same error as that case, but that might provide you with some clues around the context here.

http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1293964

My guess is that something is simply missing from your login sequence. It could be that something has gone wrong after a reboot, or the work in your cluster to try to bring it into alignment was incomplete, incorrect, or has been undone somewhere along the way. And it is quite possible for the error to be in your LOGIN.COM (whether you have made changes or not), and it is equally likely that the folks that put this configuration together didn't grok shared logical names. Or that there are simply differences between Sanjeev's and Teresa's login context.

http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1107988

This stuff is usually simple to resolve, but it's going to require wading through the login sequences used by Sanjeev and by Teresa. It would be typical to find these logical names in a shared logical name table or (minimally) in a DCL procedure invoked from LOGIN.COM or SYLOGIN.COM.

UAF changes may or may not be related to the problems here, though the typical issues with Rdb involve insufficient quotas; Rdb requires large quotas, and it's known to wedge back in the Rdb versions that were contemporary with V7.2-2. If somebody is mis-set the quotas, it is possible to cause logical name definitions to fail.

And the differences in the run-times could potentially imply quota issues or device errors.

If somebody dropped multiple process quotas to lower values, then that could well be the root problem.

The only way to get to the bottom of this stuff is connecting into the servers, and by doing some digging around and debugging of the environment.

Locally, this is usually five minutes or less to find and fix, plus time required to wade through the various layers of files and indirection. Remotely via ITRC? Not so easy. Start following your login. And find out what changed in SYSUAF.

[Shriniketan Bhagwat]

Hi,

Articles in the below like may be helpful.

https://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1275224676728+28353475&threadId=1301720
http://starlet.deltatel.ru/sys$common/syshlp/rdb070_eco1.release_notes
http://www.internet.skylink.ru/sys$common/syshlp/rdb07220.release_notes

Regards,
Ketan

[Paul Jerrom]

Looks like you are wanting to run a command file to set up logicals, but you can't find the command file because the logicalname isn;t set up.

What happens from Theresa's login when you issue the command :

$ DIR ALI_DBA_HOME

My guess this isn't set up. If it is a symbol or logical then maybe an install procedure blew away all your symbols/process logicals - in which case log in again?

[Thomas Ritter]

$ rmu/show system
will list all the open databases.

PROD_DB should point to one of them.

You use the fully qualified database name in your rmu/show corrupt_pages