Installing ISQL prevents server start
Posted in 2000
Topics: Installation, Setup & Upgrades, Versions, Editions & End-of-Life
Hi, here some experiences on installing Informix SQL to one of our database servers: Solaris 2.6, IDS 7.30UC9-1 already running, ISQL 7.30.UC1 to be installed I checked out the previous messages for installing tools after the server. Both packages are version 7.30 so I decided to try an install without shutting the server down. According to earlier hints I saved the /msg directory (THX, Dave). The installation went fine, access to the database was possible without problems, all applications were running and ISQL could be used. The success lasted until the database server had to be restarted: Complaining on missing message files and aborting the initialisation...sigh After restoring the old /msg files the server started without problems (and even ISQL is still running). Breaking the TEN rule seems not be successfully even when using products with equal 7.30 version numbers. Axel
I think that the problem was that you installed a UC1 product over a UC9-1 product. Art S. Kagel Axel Sander wrote: > > Hi, > here some experiences on installing Informix SQL to one of our database > servers: > Solaris 2.6, IDS 7.30UC9-1 already running, ISQL 7.30.UC1 to be installed > > I checked out the previous messages for installing tools after the server. > Both packages are version 7.30 so I decided to try an install without > shutting the server down. According to earlier hints I saved the /msg > directory (THX, Dave). > The installation went fine, access to the database was possible without > problems, all applications were running and ISQL could be used. > > The success lasted until the database server had to be restarted: > Complaining on missing message files and aborting the initialisation...sigh > > After restoring the old /msg files the server started without problems (and > even ISQL is still running). > > Breaking the TEN rule seems not be successfully even when using products > with equal 7.30 version numbers. > > Axel
On Thu, 06 Jan 2000 09:26:51 -0500, "Art S. Kagel" <kagel@bloomberg.net> wrote: >I think that the problem was that you installed a UC1 product over a UC9-1 >product. So I don't only have to check out the 'major' release but the 'rest' too? Is UC > TC and '-2' > greater '-1'... I didn't find out the informix numbering scheme... Axel
Axel Sander wrote: > > On Thu, 06 Jan 2000 09:26:51 -0500, "Art S. Kagel" <kagel@bloomberg.net> > wrote: > > >I think that the problem was that you installed a UC1 product over a UC9-1 > >product. > So I don't only have to check out the 'major' release but the 'rest' too? > Is UC > TC and '-2' > greater '-1'... I didn't find out the informix > numbering scheme... OK versions are as follows: M.mmPVr Where: M - Major version number (5, 6, 7, 8, 9) mm - Minor version number (ie .21, .30, etc.) P - Platform type indicator: U - 32bit Unix Platforms F - 64bit Unix Platforms (There is also a letter for 32bit version compiled on a 64bit Unix platform, don't remember). T - Windows Platforms V - Maintenance major release letter, initial releases are C major updates become D so a D is newer that a C r - Maintenance minor release letter. Any additional characters (usually -1, -2, A, B are patch versions containing a fix to one or a few specific bugs usually requested by a single customer often a back port of a fix contained in a later version that some user cannot upgrade to due to incompatibilities with 3rd party software or platform desupport). As to what to pay attention to for upgrade order... You can ignore the platform character as a particular release for all platforms use the same message files and library source/format/layout so it is safe to upgrade a U product with an F product at the same level as long as there are no other 'newer' products already installed. You can also ignore the 'additional' characters since here also new messages may be added but older ones will not go away. So you need to pay attention to M, mm, V, and r using normal alphanumeric collating. Art S. Kagel
On Thu, 06 Jan 2000 14:00:28 -0500, "Art S. Kagel" <kagel@bloomberg.net> wrote: >OK versions are as follows: > > M.mmPVr Great, thanks for all your explanations. Axel