ࡱ> M mbjbj== WWil==== =9X:>>>>>>>>WWWWWWW$sY [xW>>>>>WT>>WTTT> >>WT>WTTWW>~> $1<=H WW X09XW \T \WTnhDestroyDb 20128 (nhDestoryDb needs more error handling) 1/5/02 9:28:57 AM ad'silva Can we put some more debugging around nhDestroyDb. The first thing it asks you for is password. There is not information as to the fact that the root password is required. Further, there should be warnings about deleting data as this program starts. Other nh programs do this and we should make sure that the user really intends to delete his database and all his data 2/13/02 5:46:33 PM rhawkes Postponing for now. 5/6/02 2:51:12 PM rtrei We should put out amessage that this utility must be run by root (or Oracle) whichever. We should check that we are the correct id. I do not believe we need to warn. 7/9/02 3:06:49 PM rhawkes Assigning to Ravi for B2. 11/25/02 3:28:18 PM jkuefler Will address this in my "scripting pass" on $WSC/oracle/scripts CONTROL FILES (23839): /vobs/top/misc/instal/uninstall_ora.sh:358: rm -fr ${dirroot1}/ctl ${dirroot1}/oradata/${ORACLE_SID} /vobs/top/misc/instal/uninstall_ora.sh:360: rm -fr ${dirroot2}/ctl ${dirroot2}/oradata/${ORACLE_SID} /vobs/top/misc/instal/uninstall_ora.sh:362: rm -fr ${dirroot3}/ctl ${dirroot3}/oradata/${ORACLE_SID} 24441 (After uninstalling eHealth the following Oracle files were not removed.) 8/22/02 4:49:48 PM llopilato SYSTEM OS : WIN2K OS PATCH REV : SP2 SYSTEM NAME : Leo EHEALTH KIT : 5.6.188 KIT PATCH REV: - ORACLE KIT : 9.2 KIT DATE : 08-20-02 TEST DATE : 08-22-02 SQA CONTACT : Lee M. LoPilato AREA TESTED : InstallShield Uninstall ISSUE: ---------- After uninstalling eHealth the following Oracle files were left behind. Note that these files were added during the eHealth install.. \oracle\ora92\admin\bdump \oracle\ora92\admin\bdump\EHEALTH \oracle\ora92\admin\cdump \oracle\ora92\admin\cdump\EHEALTH \oracle\ora92\admin\udump \oracle\ora92\admin\udump\EHEALTH \oracle\ora92\database\initEHEALTH.ora \oracle\ora92\database\OraDim.Log \oracle\ora92\database\PWDEHEALTH.ORA \oracle\ora92\database\sqlnet.log \oracle\ora92\network\sqlnet.log COMMENT: ---------- 8/23/02 2:59:03 PM wzingher Downgrading to medium. This has no effect on a functioning system. 8/23/02 3:00:03 PM wzingher Also, from 24440, 8/22/02 4:34:13 PM llopilato SYSTEM OS : WIN2K OS PATCH REV : SP2 SYSTEM NAME : Leo EHEALTH KIT : 5.6.188 KIT PATCH REV: - KIT DATE : 08-20-02 TEST DATE : 08-22-02 SQA CONTACT : Lee M. LoPilato AREA TESTED : InstallShield Uninstall ISSUE: ---------- After uninstalling eHealth the following NutTrash4 directory was left. COMMENT: ---------- 8/23/02 3:01:11 PM wzingher Also, from 24447 , ISSUE: ---------- After uninstalling eHealth the following file was not removed; C:\flexlm\lmgrd 8/26/02 1:07:27 PM tfang Per Robin, re-assigning it to database group. Robin says that the nhDestroyDb should remove the following files if there is no other oracle sid directory. So that, when we run nhDestroyDb during eHealth uninstall, these files will be removed alone with eHealth. Please disregard removing "C:\flexlm\lmgrd" for this ticket. I'll take care of it separately. Thanks, -Tracy \oracle\ora92\admin\bdump \oracle\ora92\admin\bdump\EHEALTH \oracle\ora92\admin\cdump \oracle\ora92\admin\cdump\EHEALTH \oracle\ora92\admin\udump \oracle\ora92\admin\udump\EHEALTH \oracle\ora92\database\initEHEALTH.ora \oracle\ora92\database\OraDim.Log \oracle\ora92\database\PWDEHEALTH.ORA \oracle\ora92\database\sqlnet.log \oracle\ora92\network\sqlnet.log 10/2/02 1:20:35 PM rhawkes See also 24319 11/25/02 3:30:41 PM jkuefler I will add this to nhDestroyDb. 25200: TECH TIP (see end of word doc) 25293: NT env variables must be set consistently (see end of word doc) 26687: Need prereq checker for env variables (see end of word doc) nhCreateDb CONTROL FILES (23839): /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1328: ${dirroot1}/ctl/control01.ctl /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1329: ${dirroot1}/ctl/control02.ctl /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1330: ${dirroot1}/ctl/control03.ctl /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1589: -e "s@%%IFILE%%@${NH_HOME}/oracle/database/ctl_files@" /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1642: ctl_dir=${dirroot1}/ctl /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1648: cat < ${ctl_files_dir}/ctl_files /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1662: cat < ${ctl_files_dir}/ctl_files 27208: pbar. Log file, and nhiVerifyCreateDb invocation There might be other tickets floating in Remedy for this, but I cannot find them and am already starting this work. When the installer runs nhCreateDb, it does EXTRA things that should be *inside* nhCreateDb itself. I added the code to the installer, so this is not too tough to move it. When a user (or developer) runs nhCreateDb by itself, they should get a consistent log file, a decent return code (which they don't) and it shoudl VALIDATE the creation (which it doesn't). 25200: TECH TIP (see end of word doc) 25293: NT env variables must be set consistently (see end of word doc) 26687: Need prereq checker for env variables (see end of word doc) nhUpgradeToOra9ix CONTROL FILES (23839): /vobs/wsCore/oracle/scripts/nhUpgradeToOra9ix.sh:410: cp ${NH55Home}/oracle/database/ctl_files ${NH56Home}/oracle/database/ctl_files /vobs/wsCore/oracle/scripts/nhUpgradeToOra9ix.sh:411: makeNhUserOwner ${NH56Home}/oracle/database/ctl_files /vobs/wsCore/oracle/scripts/nhUpgradeToOra9ix.sh:426: replaceOracleHome ${NH56Home}/oracle/database/ctl_files 26580: need progress bar in nhiUpgradeToOra9i 11/8/02 5:48:29 PM rtrei Should be able to put one in easily, but need something for the actual migrate db 11/25/02 3:32:30 PM jkuefler I'll take care of this with my script work. 25200: TECH TIP (see end of word doc) 25293: NT env variables must be set consistently (see end of word doc) 26687: Need prereq checker for env variables (see end of word doc) nhiCheckOracle 26770: nhiCheckOracle is confused about revision Reporting 5.6:19 number 11/14/02 4:33:37 PM pstinney Using system Samoa (Sol 2.8) installed with the ehealth56 Beta 1, 11/13/02 kit, I ran nhDestroyDb then nhCreateDb. Then I ran nhGetCustDb -load -p /export/samoa1/ruh_stats to load a saved file (ruh_stats) into the new database. These commands seemed to work OK, except for two known problems, one TA nhiUpdateDbProtocol failure and one dataAnalysis/standard.dac. A message was displayed indicating the create command was successful. Then I started ehealth and the following error message was displayed: Samoa% ehealth Error: nhiCheckOracle will not work with a database that is not the latest version. Database is at version 'Reporting 5.6:19 Reporting 5.6:19', but nhiCheckOracle requires a database version of 'Reporting 5.6:19'. Please specify another database name. The ehealth console did not display. 11/14/02 5:08:29 PM rhawkes There are two identical rows in some of the key tables... 11/14/02 6:28:07 PM rpattabhi The issue here is with custDb. Since this is already a known bug on CustDb. I am closing this as a repeat. 11/15/02 7:39:49 AM rhawkes The other issue is resolved. Reopening this. 11/19/02 12:30:34 PM rhawkes Somehow running the getCustDb script on a created DB caused tables to be duplicated. 11/21/02 5:50:11 PM jkuefler In addition to tracking this down, we really must create unique indexes on a both of "one row" tables in our schema. I know NH_MACHINE in the past has also had problems. Here's a current list of tables that have one row from a NOV15 kit: % count nh% | grep 0000001 count(*) of NH_ALARM_HISTORY : 0000001 count(*) of NH_CALENDAR : 0000001 count(*) of NH_CALENDAR_RANGE : 0000001 count(*) of NH_CONVERT_STATE : 0000001 count(*) of NH_DB_MODEL : 0000001 count(*) of NH_GLOBAL_STATE : 0000001 count(*) of NH_LE_GLOBAL_PREF : 0000001 count(*) of NH_MACHINE : 0000001 count(*) of NH_SCHEMA_VERSION : 0000001 count(*) of NH_SERVICE_PROFILE : 0000001 count(*) of NH_STATS_ANALYSIS : 0000001 count(*) of NH_SYS_TA_MODE : 0000001 11/25/02 3:33:31 PM jkuefler On it. 25200: TECH TIP (see end of word doc) 25293: NT env variables must be set consistently (see end of word doc) 26687: Need prereq checker for env variables (see end of word doc) nhVerifyIngresSave 26853: *** BLOCKER *** nhVerifyIngresSave needs to handle no stats data condition 11/18/02 4:13:23 PM llopilato SYSTEM OS : HOUX 11.i OS PATCH REV : Updated Patch SYSTEM NAME : Rhode EHEALTH KIT : 11-18-02 BETA 1 Branch KIT PATCH REV: 5.0.2 P4, D4 ORACLE KIT : 9.2 during installation KIT DATE : 11-18-02 (Beta1 Branch) TEST DATE : 11-18-02 SQA CONTACT : Lee M. LoPilato AREA TESTED : Single system migration from 5.0.2 P4, D4. ISSUE: ---------- Activate never completed on this system due to the following error seen in the install log however, nhcreatedb did finish; "ERROR: last data file should be one of these files rst_b30.zip or pis_b45.zip or pii_b45.zip or bli_b47.zip or nh_hourly_volume*.zip Instead last file saved is 'etu_b50.zip': -----> rst_b30.zip MISSING (nhSaveDb was INCOMPLETE)." Mon 15:04:47 Starting database creation Output is logged to /export/rhode1/ehealth5.6/log/install/CreateDb.log 0% 25% 50% 75% 100% ||||||||||||||||||||||||||||||||||||||||||||||||||| Mon 15:27:28 Finished creating database Mon 15:27:28 Disabling 5.0.2.D04 stats roll-up Job was disabled. Mon 15:27:33 5.0.2.D04 stats roll-up disabled Mon 15:27:33 Disabling 5.6.0 stats roll-up. Mon 15:27:35 5.6.0 stats roll-up disabled Mon 15:27:35 Saving Ingres database. See log file /export/rhode1/ehealth5.0.2/log/save.log for details... Begin processing 11/18/2002 03:27:38 PM. Copying relevant files (11/18/2002 03:27:38 PM). End processing 11/18/2002 03:27:52 PM. ERROR: last data file should be one of these files rst_b30.zip or pis_b45.zip or pii_b45.zip or bli_b47.zip or nh_hourly_volume*.zip Instead last file saved is 'etu_b50.zip': -----> rst_b30.zip MISSING (nhSaveDb was INCOMPLETE). WARNING: no STATS data found. ERROR: nhSaveDb seems to have failed. Mon 15:27:52 Verification of saved Ingres database failed. ------------------------------------------------------------------------------ ^[[7m==>^[[0m eHealth 5.6.0 has been successfully installed, but has not ^[[7m==>^[[0m been activated. ^[[7m==>^[[0m ^[[7m==>^[[0m eHealth 5.0.2.D04 is still running. ------------------------------------------------------------------------------ --------------------------------------- ^[[1mPlease take care of the following 4 items:^[[0m --------------------------------------- 1) For convenience, you may wish to add the following line to the .cshrc file of the user 'nhuser': source /export/rhode1/ehealth5.6/nethealthrc.csh --------------------------------------- 2) To start eHealth, use this command: /export/rhode1/ehealth5.6/bin/nethealth --------------------------------------- 11/18/02 5:12:14 PM rhawkes The error indicates that the database save contains no stats data. Although the v5.0.2 system polled for an hour, it appears that all of the polls are bad. 11/21/02 5:59:38 PM jkuefler This is an easy one. I just need to talk to Lee or look at that system. 11/25/02 3:25:50 PM jkuefler I'll do this with the other scripting stuff. 25200: TECH TIP (see end of word doc) 25293: NT env variables must be set consistently (see end of word doc) 26687: Need prereq checker for env variables (see end of word doc) nhUpgradeOracleDb 27164: nhUpgradeOracleDb should end after warning that it must be run by root 11/26/02 1:39:29 PM jdorden ran the command as nhuser - it warned that the command should be run as root but it kept going.. it should just exit if it detects that the user is not root Nov 25 octo_install_ndsol kit ouch% nhUpgradeOracleDb Error: This program must be run as root.. Stopping servers. Password: Stopping eHealth servers. Starting database upgrade to Oracle 9i. Refer to log /export/ouch1/ehealth56/log/UpgradeOracleDb.log for more details.. Log file is in /export/ouch1/ehealth56/log/UpgradeOracleDb.log Command must be run as user root. Upgrade failed. Copying files to new locations Password: su: Sorry chmod: WARNING: can't change /export/ouch1/oracle/ora92//dbs cp: cannot create /export/ouch1/oracle/ora92//dbs/initEHEALTH.ora: Permission de nied Could not copy to '/export/ouch1/oracle/ora92//dbs/initEHEALTH.ora' Upgrade failed. Command /export/ouch1/ehealth56/bin/sys/nhiUpgradeToOra9i -nhhome55 /export/ouch 1/ehealth55/ -orahome8i /export/ouch1/oracle/ora817/ -nhhome56 /export/ouch1/ehe alth56/ -orahome9i /export/ouch1/oracle/ora92/ -logfile /export/ouch1/ehealth56/ log/UpgradeOracleDb.log -copyFiles failed.. Log file is in /export/ouch1/ehealth56/log/UpgradeOracleDb.log Command must be run as user root. Final upgrade stage not completed. Password: su: Sorry Final upgrade stage not completed: Oracle rev has not been updated Error: Command /export/ouch1/ehealth56/bin/sys/nhiUpgradeToOra9i -nhhome55 /expo rt/ouch1/ehealth55/ -orahome8i /export/ouch1/oracle/ora817/ -nhhome56 /export/ou ch1/ehealth56/ -orahome9i /export/ouch1/oracle/ora92/ -logfile /export/ouch1/ehe alth56/log/UpgradeOracleDb.log -copyFiles failed.. Error: Oracle RDBMS upgrade failed.. 11/27/02 8:34:15 AM jkuefler Got it. 25200: TECH TIP (see end of word doc) 25293: NT env variables must be set consistently (see end of word doc) 26687: Need prereq checker for env variables (see end of word doc) nhStopDb, nhStartDb, *.sh 25200: TECH TIP (see end of word doc) 25293: NT env variables must be set consistently (see end of word doc) 26687: Need prereq checker for env variables (see end of word doc) 23839: The install script does not allow "multiplexing" for Oracle 7/29/02 3:09:20 PM cestep The eHealth 5.5 installation allows us to choose up to 9 directories to create the database. Even with a 9-directory install, all of the control files are still in a single directory which is not a recommended configuration for resilience (i.e. they should be multiplexed). The install does not allow for multiplexing. This was confirmed by Ravi Pattabhi. 10/3/02 1:02:03 PM rhawkes Joe has prototyped this work. He will conduct an approach review of it. 10/3/02 1:59:20 PM jkuefler (taken from ticket 25183) 9/18/02 2:18:23 PM jkuefler nhCreateDb prompts the user for a list of directories to place oracle data on: Database Directories --------------------------------------- Oracle databases require the creation of a number of tablespaces distributed over several disks. In order to create the database, the install program needs to know which directories to create these tablespaces in. eHealth supports between 1 and 9 directories for tablespaces. Each directory must be in a different device. Enter number of directories to use for tablespaces : 3 Enter directory 1 : /export/dasher01 Enter directory 2 : /export/dasher02 Enter directory 3 : /export/dasher04 It will then create an "oradata/$ORACLE_SID" dir under each of these directories and will place database files there: /export/dasher01/oradata/EH56ON92/redo11.log /export/dasher01/oradata/EH56ON92/redo12.log /export/dasher01/oradata/EH56ON92/redo21.log /export/dasher01/oradata/EH56ON92/redo22.log etc. HOWEVER, the oracle control files are placed in a HARDCODED directory under the first dir and are MISSING the ORACLE_SID: /export/dasher01/ctl/control01.ctl /export/dasher01/ctl/control02.ctl /export/dasher01/ctl/control03.ctl There are TWO PROBLEMS with this scheme: (1) the control files should have been sprinkled across the disks (I think this is already in another ticket) (2) you cannot have more than one eHealth on a machine unless you are clever enough to know about this limitation. --> this will create great confusion for engineers. it might affect a customer, too, but by the time someone figures out what the problem is, they will have trashed their other database. We need to put the control files like this: /export/dasher01/oradata/control01.ctl /export/dasher02/oradata/control02.ctl /export/dasher04/oradata/control03.ctl 10/3/02 2:02:47 PM jkuefler Waiting for an approach review on Monday. Have a working prototype. 10/28/02 2:38:02 PM jkuefler Approach was written and is approved. Here's what we are going to do: Virgin 5.6 installs automatically put the control files in the right spots 5.5 Customers handle this with documentation (forthcoming) Customers upgrading from 5.5 to 5.6 automatically move their control files into the right spots 10/30/02 2:29:47 PM jkuefler Not working on this until the B2 branch is created. 11/21/02 6:00:49 PM jkuefler Here's the code that needs to change: % codegrep /vobs /ctl -W codegrep: reading file extensions from '/home/eng/jkuefler/bin/codegrep.ext'... codegrep: grep for '/ctl' in '/vobs'... codegrep: find /vobs -name '*.*' -print 2>&1 codegrep: recursing '/vobs' for 31 file extensions... ------------------------------------------------------------------------------- /vobs/top/misc/instal/uninstall_ora.sh:358: rm -fr ${dirroot1}/ctl ${dirroot1}/oradata/${ORACLE_SID} /vobs/top/misc/instal/uninstall_ora.sh:360: rm -fr ${dirroot2}/ctl ${dirroot2}/oradata/${ORACLE_SID} /vobs/top/misc/instal/uninstall_ora.sh:362: rm -fr ${dirroot3}/ctl ${dirroot3}/oradata/${ORACLE_SID} /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1328: ${dirroot1}/ctl/control01.ctl /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1329: ${dirroot1}/ctl/control02.ctl /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1330: ${dirroot1}/ctl/control03.ctl /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1589: -e "s@%%IFILE%%@${NH_HOME}/oracle/database/ctl_files@" /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1642: ctl_dir=${dirroot1}/ctl /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1648: cat < ${ctl_files_dir}/ctl_files /vobs/wsCore/oracle/scripts/nhCreateDb.sh:1662: cat < ${ctl_files_dir}/ctl_files /vobs/wsCore/oracle/scripts/nhUpgradeToOra9ix.sh:410: cp ${NH55Home}/oracle/database/ctl_files ${NH56Home}/oracle/database/ctl_files /vobs/wsCore/oracle/scripts/nhUpgradeToOra9ix.sh:411: makeNhUserOwner ${NH56Home}/oracle/database/ctl_files /vobs/wsCore/oracle/scripts/nhUpgradeToOra9ix.sh:426: replaceOracleHome ${NH56Home}/oracle/database/ctl_files ------------------------------------------------------------------------------- codegrep: summary of grepstr='/ctl' in '/vobs': 476 : directories entered 53725 : total files considered 485 : filenames with no ext skipped (see -n) 32362 : filenames with wrong ext skipped 17 : bad links encounterd (see -e) 4 : read errors encounterd (see -e) 653 : binary files skipped (see -b) 20204 : files actually grepped 2440 : grep errors encountered (see -e) 13 : total instances of grepstr found 3 : distinct files found with grepstr 3 : *.sh files found with '/ctl' codegrep: took: 18 mins, 31 secs. COMMON CHANGES ACROSS ALL SHELL SCRIPTS 27040: Hardening Need to "Harden" database scripts like nhStopDb, nhStartDb, nhServer,nhCreateDb,nhDestroyDb. as to which user-type can run them. 25200: TECH TIP: please check env variable settings 9/18/02 6:43:46 PM rtrei I need to document what the environment variable setting should be for the various scenarios. Specifically, it is illegal ot have a NH_ORACLE_HOME_OLD <> NH_ORACLE_HOME but have NH_HOME_OLD = NH_HOME This is because the database should be upgrade to 9i as part of an inplace update. But if problems happen, need to document how to set env variables to get them out of this spot. 11/25/02 3:31:16 PM jkuefler I'll include this in the script hardening. 25293: NT env variables must be set consistently 9/20/02 3:34:53 PM rtrei Tracy-- It is vital that the NH_HOME and NH_ORACLE_HOME environment variables be set consistently. If you capitalize the drive in one place, you must do so in all others. The scripts compare the values to make decisions. I just encountered a bug because NH_ORACLE_HOME= L:\oracle\ora92 and NH_ORACLE_HOME_OLD=l:\oracle\ora92 So be sure that the _OLD and _NEW variants are as consistent as possible, please. 9/20/02 6:24:07 PM tfang Talked with Robin, will make sure that the drive letter to be Upper case. 9/23/02 10:57:06 AM wzingher Robin, customers can set these env vars, and we can't enforce caps or no caps if the Windows operating system doesn't. The scripts really should handle this. 9/26/02 1:54:08 PM rhawkes For the most part this is done by the installer -- customers won't readily need to do this. It is important for the release though. Targetting for Beta 2. 11/25/02 3:24:43 PM jkuefler I'll do this when I "harden" the scripts in $WSC/oracle/scripts 26687: Need prereq checker for env variables 11/13/02 1:05:46 PM rpattabhi Also see #26676. We need a way in 5.6 for all our scripts to do some basic checks for our environment. This needs an approach. I bug 26676 at cegetel we found a bad .cshrc can cause ehealth;s createdb to stop working in a rather strange way. It took a lot of time to figure out what was going on. But it turned out that a su to oracle from a root user was sourcing the nhuser's .cshrc file causing all the prolembs. The problem was that somehow the nhuser's .cshrc file got changed such that this file was overriding the PATH environment variable. This caused some of the oracle executables we need to create a database like sqlplus etc to not be found. Once we fixed the .cshrc file in the ehealth admin account the create db started to work. Although it seems rather obvious now it was not easy to find as we were finding a simple su to oracle would lose the path and we couldnt figure out for a while what was stomping it. Luckily Raj saw some environment variables being set by the nhuser account and sure enough it was the nhuser's .cshrc causing the problem During create db our script su's to oracle. And in so doing we were getting our ehealth environment broken. There isnt much we can do to fix such a problem. Our installer does not check the .cshrc file. Nor can we dictate what the user set's the ehealth users environment to. In 5.6 the ehealth user and the oracle user are one and the same and hence we should not face this issue. However for 5.5 I dont know if there is any real work we can do to prevent this issue. I can log a ticket in 5.6 to have a prereq environment checker in all of our script so that the scripts can detect a busted environment. -Ravi >-----Original Message----- >From: Pattabhi, Ravi >Sent: Wednesday, November 13, 2002 10:01 AM >To: Jathar, Raj >Cc: Hawkes, Richard; Ciupa, Dominique; McCabe, Rob; Betz, >Mike; Chapman, >Sheldon; Venuto, Donna; Mudgett, Chris; Bui, Ha >Subject: RE: Updated: Conference Call with Cegetel for Action Plan >Update > > >Raj: 11/13/02 3:33:55 PM rpattabhi I am adding Raj's comments to this bug. Sounds like we should force a source of nethealthrc.sh into all our scripts. We have to weigh this against doing upgrades because we have a need to also toggle between 5.5 and 5.6 for the upgrade. -Ravi Hi Ravi, Thanks for your time and patience with this issue. I am not so sure that it could not have been prevented. all of the nh_ scripts in bin have a verify environment procedure and one of the things that it establishes is where exactly NH_HOME is and whether it contains a valid install based on a few rudimentary metrics. Once it knows that, it has a valid nethealthrc.sh to work with. that should give us the current ORACLE_HOME. The reason we used to (or still do) is that we did not want to be at the mercy of the user's env (and after this we can all appreciate why). There are all sort of pathological conditions that could arise as a result of this, e.g. instead of being the eH user, had I been logged in as myself and then su'ed to other users en route to being Oracle, I would've been at the mercy of my user env, and the chances of that having eH set up are slim, if any. I think that while checking is definitely a good thing, in this case letting the user know that it wasn't set up correctly didn't really help either. Anyway, to cut a long story short, I feel where possible, we should stick the requisite dir spec in the path explicitly. Thanks again... - raj -----Original Message----- From: Pattabhi, Ravi To: Pattabhi, Ravi; Jathar, Raj Cc: Hawkes, Richard; Ciupa, Dominique; McCabe, Rob; Betz, Mike; Chapman, Sheldon; Venuto, Donna; Mudgett, Chris; Bui, Ha; DB_team Sent: 13/11/2002 12:53 Subject: RE: Updated: Conference Call with Cegetel for Action Plan Update The problem was that somehow the nhuser's .cshrc file got changed such that this file was overriding the PATH environment variable. This caused some of the oracle executables we need to create a database like sqlplus etc to not be found. Once we fixed the .cshrc file in the ehealth admin account the create db started to work. Although it seems rather obvious now it was not easy to find as we were finding a simple su to oracle would lose the path and we couldnt figure out for a while what was stomping it. Luckily Raj saw some environment variables being set by the nhuser account and sure enough it was the nhuser's .cshrc causing the problem During create db our script su's to oracle. And in so doing we were getting our ehealth environment broken. There isnt much we can do to fix such a problem. Our installer does not check the .cshrc file. Nor can we dictate what the user set's the ehealth users environment to. In 5.6 the ehealth user and the oracle user are one and the same and hence we should not face this issue. However for 5.5 I dont know if there is any real work we can do to prevent this issue. I can log a ticket in 5.6 to have a prereq environment checker in all of our script so that the scripts can detect a busted environment. -Ravi 11/14/02 9:17:23 AM rpattabhi Raj: I have added your comments to the bug #26687. In effect what your saying is that we should always validate the environment and source nethealthrc.sh. Note that most script already do this. However there are scripts that are not user visible like installdb that assume a certain environment. In 5.6 there will not be any su'ing so this problem for the most part will dissappear. Once a script validates the environment all underlying scripts dont have to do the same. Also, in 5.6 we have actually been hurt by this kind of a forced env check. It hurt us for some of the online upgrade with no down time between 5.5 and 5.6. Some of the scripts like load, save, startdb stopdb etc need to work even when we are in a limbo state with 5.6 utilities talking to a 5.5 db(limbo mode). So we need some careful thought before we make all the necessary changes. -Ravi 11/25/02 3:34:03 PM jkuefler On it. ;<OQCD`az{>?LM\_s$#%(%;%=%%&111119289999{:~::OIOOPQRV2Vmmmmmm^JaJCJOJQJaJC  ;<WUOPQh27$8$H$m2  / B Z k ~  >  3 X 7$8$H$X    $ / K   , = U m &'()*FWXalLMj==b @ABCDTj `abtz{+,>?VG7$8$H$GPQn 6LM\]^_:t7$8$H$t5{|&OvNOPn$ % & C 7$8$H$C ,!-!b!c!!!!!/"e"""#=#s###$K$L$M$N$k$r$7$8$H$r$s$$$$$ %#%$%%%&%'%(%;%<%=%%%%%%%&;&b&&&&&7$8$H$&&' ''''(H((((((%)Y)Z)[))))))) *J*K*p***7$8$H$*+6+j+++*,H,n,,,,B-`-n---.L.M.u..../;/b/c///7$8$H$////0[0q0r0s0t0000000%1&161L1}11111111927$8$H$92:2V2233+3U3g3q3334B4t4444455:55551666627<77$8$H$<7F777+8|88888888 9"9S9i99999999999":8:7$8$H$8:e:{:|:}:~:::8;;<<@<A<\<<<<<<<<I=J=_=== >M>7$8$H$M>>>>?&?K?p?q????@J@{@@@@@A1A2AYAAAAAABB,C7$8$H$,CwCxCCCC%D&D'DCDmDDDDDDD:EvEEEEEEE,F-FJFpFqF7$8$H$qFFFG/GeGGHHHI}JJ+KKLLL M(MIMzMMMMN@NkNNN7$8$H$NNOOO8OIOJOOOOPPPCPoPzP{PPPPPPQ9Q:QgQQQ7$8$H$QQQQRR/R7RgRRRRRS/SSSvSwSSSSS-T.TKTTTUPU7$8$H$PUUUUUVVVVV2VPVaVbVWWzZ{ZP\Q\\\\\\]B]S]]7$8$H$]]]^^^ ^&^'^(^F^3_4_:_;_D_E_cccccccd4dddee7$8$H$ee`eee:fff gSggggg/hxhhiLiwixiijjj j j(j-j.j7$8$H$.jllmmmmmmmmmmm7$8$H$ / =!"#$% i<`< NormalCJOJQJ_HmH sH tH ` Heading 1F$$<$d0&d0-D @&M N0P0'5B*CJ KH OJQJ\^JaJ phT@T Heading 2$<@& 56CJOJQJ\]^JaJ<A@< Default Paragraph Fonti ;<WUOPQh2/BZk~>3X$/K  , = U m     & ' ( ) * F W X a l  L M j  = b  @ABCDTj `abtz{+,>?VGPQn 6LM\]^_:t5{|&OvNOPn$%&C,-bc/e=s K L M N k r s !#!$!%!&!'!(!;!>,?w?x????%@&@'@C@m@@@@@@@:AvAAAAAAA,B-BJBpBqBBBC/CeCCDDDE}FF+GGHHH I(IIIzIIIIJ@JkJJJJKKK8KIKJKKKKLLLCLoLzL{LLLLLLM9M:MgMMMMMMNN/N7NgNNNNNO/OSOvOwOOOOO-P.PKPPPQPQQQQQRRRRR2RPRaRbRSSzV{VPXQXXXXXXYBYSYYYYZZZ Z&Z'Z(ZFZ3[4[:[;[D[E[_______`4```aaa`aaa:bbb cSccccc/dxddeLewexeefff f f(f-f.fhhiiiiiiiiiii000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00M0M0M0M0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0_0M0s 0M0 0M0 0 0 0 0 0 00(!0(!0(!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0=!0(!0&-0(!0L-0(!0-0-0- 00-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-040-0"50-0i50i50i5 00505050505050505086086086086 00~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~60~6 00K08K08K08K08K0K0K0K0K0K0K0K0K0K0K0K0K0K0K0K0K0K0K0K0K0K0K0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0M0K0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0R0Rm82X =GtC r$&*/92<78:M>,CqFNQPU]e.jm9;<=>?@ABCDEFGHIJKLMNOPQRm: NV}WY&.^`bdBJ = E  & e h 3>tw7@^gGTV_im}(2akIO  =F}(+M[ft'-7EP 3ftW` !(!:!T!f!!!""q#{#$$d$l$''((O(W(V-Y--------.N.U.. //*/00005191a2h22222<3>3(4*4b4i444,5/5u5{555555555D6J6W6Z66668>88999M:X:::::CCCCFDHDJDLDDDDDF F)F2FeFlFFFFFGG!G*GGGGGGGHHRHcHHHHHIIIIJJJJJKK KqKyK{KKKKKKLL)M0MnMqMMMOOBPJPjPmPnPrPQQRR$R'RRRSSSSSSSSSSTTUUUUUUVV^VVVVV XXuX{XY YGYMYOYRYiYnYYYYYYZ!Z$ZRZWZ[[S]V]]]#^(^z^}^^^__` `` `(`.`0`3`I`N```````:aBabbbbc"c}ccccdd2e6eee(f+f$g-gngtgggggDhGhhhhhi }WY!.VXX\%*6=JPry>B 7=\b   # A K Z c q {  e h Q W n t   A G f l UXBG,127,= w{7:M[tv%v~05fk >Cty  k q !!(!:!!!!!!!""B"I"f"p"""""""####O$R$$$K&o&q't'''n((E*G*****[,],7-:-~------V.Y...//R/T/000000005191127222<3>333+4.4|4444 55T5W5555555#6&6f6i666778>8888999 ::M:X:::::;;6;9;[;^;;;<<= ===G>J>>>>>1?4?sB{BBBBBC C/C7CCC@DDDDD EEEEFFFG[G_GGGLHPHHHII*I1IMIRI|IIIIIIIJ!J(JCJIJpJtJJJJJJJKKKKCLKLoLxLLLLLMMgMiMgNrNNNOOOOQ4QPQTQQQPR`RRRSST"TTTVVeV5W?W X X[[\\]]__:aIa`adaaaaabb:bAbbbbb ccScYccccc/d3d\dfdxdddde eLePeeeffgg+i.iiii333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 Joseph Kuefler]C:\WINNT\Profiles\jkuefler\Application Data\Microsoft\Word\AutoRecovery save of Document5.asdJoseph KueflerU:\jkuefler\doc\ShellWork.docJoseph Kuefler]C:\WINNT\Profiles\jkuefler\Application Data\Microsoft\Word\AutoRecovery save of ShellWork.asdJoseph KueflerU:\jkuefler\doc\ShellWork.docJoseph Kuefler]C:\WINNT\Profiles\jkuefler\Application Data\Microsoft\Word\AutoRecovery save of ShellWork.asdJoseph KueflerU:\jkuefler\doc\ShellWork.doc@55`_55ip@UnknownGz Times New Roman5Symbol3& z ArialC"MS Sans Serif?5 z Courier New"qhkfkf)J+W,!20 k2Q nhDestroyDbJoseph KueflerJoseph KueflerOh+'0   < H T`hpx nhDestroyDbhDeJoseph Kuefleroseose Normal.dotlJoseph Kuefler3seMicrosoft Word 9.0@6F@+@1J+W՜.+,0 hp  Concord, k  nhDestroyDb Title  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry F0 $11TableT \WordDocumentSummaryInformation(DocumentSummaryInformation8CompObjjObjectPool0 $10 $1  FMicrosoft Word Document MSWordDocWord.Document.89q