Re: IDS 11.50.xC6 is out...

Neil Truby schrieb: > "Neil Truby" > <neil.truby@ardenta.com> wrote in message > news:7q71ljFttgU1@mid.individual.net... >> >> "Ian Michael Gumby" <im_gumby@hotmail.com> wrote in message >> news:mailman.416.1262356165.6236.informix-list@iiug.org... >> I'd choose the J version. Most likely if they are the same, then >> either they replicated it, or if they are supposed to be the same, but >> are not, then they probably goofed on something small like in a >> deployment detail, and they rewrap'd it... >> >> Tried the "J" one. >> >> "The wizard cannot continue because of the following error: could not >> load wizard specified in /wizard.inf (104)" > > I still can't get past this error and get 11.5UC6 installed, despite > hours of Googling, if anyone has any suggestions ...? > > thanks > Neil Hi Neil, /* old man ranting */ WHO on this earth, has an advantage of all that very unnecessary and annoying java installer thing? Anyone have only 1 reason, why this was created? I want/need to learn something. /* end of omr */ Now, what we did when we had problems on SuSE 11.2: We deinstalled SuSE java completely. Then the JRE, which comes with the package was installed and installation of IDS was possible. But then we did some analysis, created a good old cpio archive, and alas: Next installation (using the cpio archive) was done in less than 30 secs, instead of 1.5 minutes! And yes, we use very fast disks :) Note to IBM officials: PLEASE give us a version, where the java thing can be avoided altogether. Java in first place always means incompatibilty issues and other unnecessary problems! dic_k -- Richard Kofler SOLID STATE EDV Dienstleistungen GmbH Vienna/Austria/Europe

Richard Kofler wrote: > Note to IBM officials: > PLEASE give us a version, where the java thing can be > avoided altogether. Java in first place always means > incompatibilty issues and other unnecessary problems! Can I suggest we all log a feature request with technical support for a non-Java, non-RPM, non-anything tarball install option? -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com I will now proceed to pleasure myself with this fish. -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

Richard Kofler wrote: <Use of Java installer for Informix product> > > /* old man ranting */ > WHO on this earth, has an advantage of all that very > unnecessary and annoying java installer thing? > Anyone have only 1 reason, why this was created? > I want/need to learn something. > /* end of omr */ > /* Old man speculating */ Customer: "WTF is this 'tarball'? WTF is a gzip?" IBM PHB: "Dang, how can we have *one* installer for all platforms, including Windows?" Fresh faced enthusiastic IBM Intern: "A single Java app works, without recompilation, on Unix, Linux, MacOS, Windows etc. Write once, run everywhere!" IBM PHB: "Make it so!" /* end of OMS */ -- RGB - who prefers .tgz to .cpio :-)

> Fresh faced enthusiastic IBM Intern: "A single Java app works, without > recompilation, on Unix, Linux, MacOS, Windows etc. Write once, run > everywhere!" Whishfull thinking, in your install app you have to check for windhoze anyway since it has a registry and deal with that. If you build an installer for unix/linux(read tar folowed by an install script to set permissions etc) and one for windhoze you should be covered. so you have a lot of extra unneeded crap in the installer. One could build a java app which does the configuring of an example instance in java. That means someone who wants to do a quick install and config is not bothered with the java crap. Superboer. On 5 jan, 16:06, RedGrittyBrick <RedGrittyBr...@spamweary.invalid> wrote: > Richard Kofler wrote: > > <Use of Java installer for Informix product> > > > > > /* old man ranting */ > > WHO on this earth, has an advantage of all that very > > unnecessary and annoying java installer thing? > > Anyone have only 1 reason, why this was created? > > I want/need to learn something. > > /* end of omr */ > > /* Old man speculating */ > > Customer: "WTF is this 'tarball'? WTF is a gzip?" > > IBM PHB: "Dang, how can we have *one* installer for all platforms, > including Windows?" > > Fresh faced enthusiastic IBM Intern: "A single Java app works, without > recompilation, on Unix, Linux, MacOS, Windows etc. Write once, run > everywhere!" > > IBM PHB: "Make it so!" > > /* end of OMS */ > > -- > RGB > - who prefers .tgz to .cpio :-)

Superboer wrote: >> Fresh faced enthusiastic IBM Intern: "A single Java app works, without >> recompilation, on Unix, Linux, MacOS, Windows etc. Write once, run >> everywhere!" > > Whishfull thinking, in your install app you have to check for windhoze > anyway since it has a registry and deal with that. > If you build an installer for unix/linux(read tar folowed by an > install script to set permissions etc) and one for windhoze you > should be covered. > > so you have a lot of extra unneeded crap in the installer. > > > One could build a java app which does the configuring of an example > instance in java. > That means someone who wants to do a quick install and config is not > bothered with the java crap. Why are you arguing with a hypothetical fresh-faced enthusiastic IBM Intern who didn't post here and who probably doesn't exist? ;-) -- RGB

> Date: Tue, 5 Jan 2010 15:06:27 +0000 > From: RedGrittyBrick@spamweary.invalid > Subject: Re: IDS 11.50.xC6 is out... > To: informix-list@iiug.org > > > > > > /* old man ranting */ > > WHO on this earth, has an advantage of all that very > > unnecessary and annoying java installer thing? > > Anyone have only 1 reason, why this was created? > > I want/need to learn something. > > /* end of omr */ > > > > /* Old man speculating */ > > Customer: "WTF is this 'tarball'? WTF is a gzip?" > God you guys are worse than old women going on the way you're complaining. Look, the simple answer is that you don't blame Java, but the senior IBM developers who don't properly educate the young folk in how to do this properly. Its not that Java is a bad thing, its just that the implementation of the java installer is pretty messed up because they (IBM) didn't write a good installer. If I understand the 'pain', IBM, in their infinite wisdom decided that they'd like to simplify everyone's life and offer a nice easy GUI tool. Because they don't know what is out there on the customer's machine, they decide to bundle a JRE and then install it off and use it instead of the java version already on the server. This is a simple thing to fix. Really. But of course being IBM and being the fact that certain folks at IBM have brown necks, one knows with 100% certainty, they will never get this straight.... but being the optimist that I am, lets see if we can try.... First, instead of bundling a JRE, the 'downloader' can do a simple command of $> which java . (The $> is an attempt of showing a generic Unix/Linux command prompt.) If the result is null or rather the error message when one can't find a certain unix program in their $PATH environment variable, the IDS install can then ask the User/Sysadmin/DBA/wonk/whatever to either correct their PATH shell variable to include their java, or to download a JRE of java and then add it to their environment variables. NOTE: If the wanker can't properly bring down a JRE, install it in to some /opt/blah/blah directory, then set their PATH and shell environment to see it, then they need to call Art, pay him shit loads of money to do it for them. :-) Then they have Java. If they do have Java, then the installer can do a check to see which version of Java is installed. Again its pretty straight forward... $> java -version Then the installer can check to see if the version they have is the same or greater than the version used in the installer. Again, if not, the installer can recommend that the wanker go out and install a newer version of java in some blah-blah blah directory and point to it in their shell environment. Other companies do this, like err Sun for example. This will solve their java problem... kind of reminds me of their perl fiasco and what sent Timmy off the deep end a few years back. (Remember when IDS was trying to install its own copy of perl? The point is that you can create a java deployment tool, done right and without these problems. Now the reason we see these nice and nifty graphic tools is that some of the younger DBAs feel that their job is only as a DBA and not do any sysadmin work. Young sysadmins want a nice nifty graphic tool because they are being tasked to manage 100s of machines and its easier to do it from a graphic terminal than from using putty and or ssh to issue commands... But hey! what do I know? Its not like I've got to write up some documents detailing how to install and build a cloud or anything... ;-) _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/

"Richard Kofler" <richard.kofler@chello.at> wrote in message news:e37c3$4b432cda$547019ee$19562@news.chello.at... > Now, what we did when we had problems on SuSE 11.2: > We deinstalled SuSE java completely. > Then the JRE, which comes with the package was installed and > installation of IDS was possible. I've done that (uninstalling Java): [root@localhost crap]# rpm -qa | egrep "java|jdk|jre" sun-javadb-javadoc-10.4.2-1.1 java-1.4.2-gcj-compat-1.4.2.0-40jpp.115 sun-javadb-common-10.4.2-1.1 sun-javadb-demo-10.4.2-1.1 sun-javadb-client-10.4.2-1.1 sun-javadb-core-10.4.2-1.1 sun-javadb-docs-10.4.2-1.1 Now I get: [root@localhost crap]# ./ids_install -javahome none (some java class messages ....) This application requires a Java Run Time Environment (JRE) to run. Searching for one on your computer was not successful. Please use the command line switch -javahome to specify a valid JRE. For more help use the option -help.

On 05/01/2010 15:06, RedGrittyBrick wrote: <snip> > Fresh faced enthusiastic IBM Intern: "A single Java app works, without > recompilation, on Unix, Linux, MacOS, Windows etc. Write once, run > everywhere!" > Typo Write once, crash everywhere -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

Ian Michael Gumby wrote: > > > > Date: Tue, 5 Jan 2010 15:06:27 +0000 > > From: RedGrittyBrick@spamweary.invalid > > Subject: Re: IDS 11.50.xC6 is out... > > To: informix-list@iiug.org > > > > > > > > > > > /* old man ranting */ > > > WHO on this earth, has an advantage of all that very > > > unnecessary and annoying java installer thing? > > > Anyone have only 1 reason, why this was created? > > > I want/need to learn something. > > > /* end of omr */ > > > > > > > /* Old man speculating */ > > > > Customer: "WTF is this 'tarball'? WTF is a gzip?" > > > > God you guys are worse than old women going on the way you're complaining. I could agree with that, although it would not be politicaly correct of course... > Its not that Java is a bad thing, its just that the implementation of > the java installer is pretty messed up because they (IBM) didn't write a > good installer. If that was proved to be true, I could also agree with that. > If I understand the 'pain', IBM, in their infinite wisdom decided that > they'd like to simplify everyone's life and offer a nice easy GUI tool. > Because they don't know what is out there on the customer's machine, > they decide to bundle a JRE and then install it off and use it instead > of the java version already on the server. You don't. I wonder if you bothered to read the thread... The installer will use any "java" found on the system, and that is the beginning of most problems. Specially because some "pure" GPL distributions don't use the "standard" JRE. And apparently (oh, oh surprise, this "other" java works differently from the "standard") IBM also provides a way to force the utilization of the bundled JRE. And Neil apparently had problems with this. Let me tell you I've used the JAVA installers on Linux, AIX, HP-UX, Tru64 and Solaris, and I don't recall having problems with the bundled installer. I'm not sure what is happening with Neil's environment. It can be some xC6 specific issue of course... > > This is a simple thing to fix. Really. But of course being IBM and being > the fact that certain folks at IBM have brown necks, one knows with 100% > certainty, they will never get this straight.... but being the optimist > that I am, lets see if we can try.... > > First, instead of bundling a JRE, the 'downloader' can do a simple > command of $> which java . (The $> is an attempt of showing a generic > Unix/Linux command prompt.) If the result is null or rather the error > message when one can't find a certain unix program in their $PATH > environment variable, the IDS install can then ask the > User/Sysadmin/DBA/wonk/whatever to either correct their PATH shell > variable to include their java, or to download a JRE of java and then > add it to their environment variables. NOTE: If the wanker can't > properly bring down a JRE, install it in to some /opt/blah/blah > directory, then set their PATH and shell environment to see it, then > they need to call Art, pay him shit loads of money to do it for them. :-) > So... nice lecture. But the fact is that the install script does it more or less as you describe... Useless talk... > Then they have Java. > > If they do have Java, then the installer can do a check to see which > version of Java is installed. Again its pretty straight forward... $> > java -version > > Then the installer can check to see if the version they have is the same > or greater than the version used in the installer. > Again, if not, the installer can recommend that the wanker go out and > install a newer version of java in some blah-blah blah directory and > point to it in their shell environment. > > Other companies do this, like err Sun for example. Nice idea. But what happens when the issue is not the version, but instead the "flavour"? The Java vs non-Java installer is an endless discussion. I believe we all want an installer that works. Even shell script is not standard! And I remember issues with the shell scripts in the older installers... So Java vs non-Java will not get us anywhere... Regards. P.S.: I haven't installed xC6 (GA version) yet. I did set it up for silent installation and asked the sysadmins to install it. No errors reported... This was on HP-UX. P.S.S.: Neil, the machine notes should mention the supported Linux versions. By no means I'm suggesting we must use a supported Linux version for test/development/whatever except production systems. But it can probably make a difference. Neil, did you uncompress the *.tar or run the *.bin with user informix? If not, can you try it?

Sigh Fernando, I wish you'd stop to think before you post. First, I am working with a client were part of my job is to build out a cluster of machines. While the hardware guys did a bang up job of building out the machines and installing the basic RHAT, ran in to a slight problem... It appears the default version of JAVA was 1.4 and I need 1.5+ (current is 1.6.something...). Of course I'm not using a java installer app, I'm using yum. So when I first started yum to bring down the software, the download package did a dependency check. It saw that I didn't have the correct version of Java. So I had two options... One I could use yum and bring down and replace the reference build's java, or I could create a directory in /opt and pull down either a JRE or JDK, set it up independent of the reference version and then run yum... Granted this is yum, but the concept is the same... The point is that you can write an install program that is intelligent enough to check to see which version of the java is there and if its not the correct version, you can show an error and then stop the install until it sees the right version. My guess is that the team responsible for this is sitting in Mumbai ?sp? without appropriate oversight. Not some intern. With respect to your "Some linuxes don't use standard jre(s) ..." , and that brings a resounding WTF? As in WTF are you blathering about? Think about it... I can go to Sun and pick up any JRE or JDK for free. Tar? Yup. Gzip? Yup. RPM? Yup. Got it? And if its not part of the Linux version you chose to use, then who's fault is that? I mean I could go on to say ... what are you doing that is outside of Sun's reference JRE? In short. get a friggin clue. You're starting to sound like Serge. But hey! What do I know? Its not like my current title is 'Solutions Architect' or something like that. As if I really pay an attention to what they call me, as long as the projects are fun and they pay their bills on time. -G > From: domusonline@gmail.com > Subject: Re: IDS 11.50.xC6 is out... > Date: Tue, 5 Jan 2010 22:47:01 +0000 > To: informix-list@iiug.org > > Ian Michael Gumby wrote: > > > > > > > Date: Tue, 5 Jan 2010 15:06:27 +0000 > > > From: RedGrittyBrick@spamweary.invalid > > > Subject: Re: IDS 11.50.xC6 is out... > > > To: informix-list@iiug.org > > > > > > > > > > > > > > > > /* old man ranting */ > > > > WHO on this earth, has an advantage of all that very > > > > unnecessary and annoying java installer thing? > > > > Anyone have only 1 reason, why this was created? > > > > I want/need to learn something. > > > > /* end of omr */ > > > > > > > > > > /* Old man speculating */ > > > > > > Customer: "WTF is this 'tarball'? WTF is a gzip?" > > > > > > > God you guys are worse than old women going on the way you're complaining. > > I could agree with that, although it would not be politicaly correct of > course... > > > > Its not that Java is a bad thing, its just that the implementation of > > the java installer is pretty messed up because they (IBM) didn't write a > > good installer. > > If that was proved to be true, I could also agree with that. > > > If I understand the 'pain', IBM, in their infinite wisdom decided that > > they'd like to simplify everyone's life and offer a nice easy GUI tool. > > Because they don't know what is out there on the customer's machine, > > they decide to bundle a JRE and then install it off and use it instead > > of the java version already on the server. > > > You don't. I wonder if you bothered to read the thread... > The installer will use any "java" found on the system, and that is the > beginning of most problems. Specially because some "pure" GPL > distributions don't use the "standard" JRE. And apparently (oh, oh > surprise, this "other" java works differently from the "standard") > > IBM also provides a way to force the utilization of the bundled JRE. > And Neil apparently had problems with this. Let me tell you I've used > the JAVA installers on Linux, AIX, HP-UX, Tru64 and Solaris, and I don't > recall having problems with the bundled installer. I'm not sure what is > happening with Neil's environment. It can be some xC6 specific issue of > course... > > > > > This is a simple thing to fix. Really. But of course being IBM and being > > the fact that certain folks at IBM have brown necks, one knows with 100% > > certainty, they will never get this straight.... but being the optimist > > that I am, lets see if we can try.... > > > > First, instead of bundling a JRE, the 'downloader' can do a simple > > command of $> which java . (The $> is an attempt of showing a generic > > Unix/Linux command prompt.) If the result is null or rather the error > > message when one can't find a certain unix program in their $PATH > > environment variable, the IDS install can then ask the > > User/Sysadmin/DBA/wonk/whatever to either correct their PATH shell > > variable to include their java, or to download a JRE of java and then > > add it to their environment variables. NOTE: If the wanker can't > > properly bring down a JRE, install it in to some /opt/blah/blah > > directory, then set their PATH and shell environment to see it, then > > they need to call Art, pay him shit loads of money to do it for them. :-) > > > > So... nice lecture. But the fact is that the install script does it more > or less as you describe... Useless talk... > > > Then they have Java. > > > > If they do have Java, then the installer can do a check to see which > > version of Java is installed. Again its pretty straight forward... $> > > java -version > > > > Then the installer can check to see if the version they have is the same > > or greater than the version used in the installer. > > Again, if not, the installer can recommend that the wanker go out and > > install a newer version of java in some blah-blah blah directory and > > point to it in their shell environment. > > > > Other companies do this, like err Sun for example. > > Nice idea. But what happens when the issue is not the version, but > instead the "flavour"? > > The Java vs non-Java installer is an endless discussion. I believe we > all want an installer that works. Even shell script is not standard! And > I remember issues with the shell scripts in the older installers... So > Java vs non-Java will not get us anywhere... > > Regards. > > P.S.: I haven't installed xC6 (GA version) yet. I did set it up for > silent installation and asked the sysadmins to install it. No errors > reported... This was on HP-UX. > > P.S.S.: Neil, the machine notes should mention the supported Linux > versions. By no means I'm suggesting we must use a supported Linux > version for test/development/whatever except production systems. But it > can probably make a difference. > Neil, did you uncompress the *.tar or run the *.bin with user informix? > If not, can you try it? > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list _

Ian Michael Gumby wrote: > Sigh Fernando, I wish you'd stop to think before you post. > > First, I am working with a client were part of my job is to build out a > cluster of machines. While the hardware guys did a bang up job of > building out the machines and installing the basic RHAT, ran in to a > slight problem... > > It appears the default version of JAVA was 1.4 and I need 1.5+ (current > is 1.6.something...). > Of course I'm not using a java installer app, I'm using yum. > > So when I first started yum to bring down the software, the download > package did a dependency check. > It saw that I didn't have the correct version of Java. > > So I had two options... > > One I could use yum and bring down and replace the reference build's > java, or I could create a directory in /opt and pull down either a JRE > or JDK, set it up independent of the reference version and then run yum... > > Granted this is yum, but the concept is the same... > > The point is that you can write an install program that is intelligent > enough to check to see which version of the java is there and if its not > the correct version, you can show an error and then stop the install > until it sees the right version. > > My guess is that the team responsible for this is sitting in Mumbai ?sp? > without appropriate oversight. Not some intern. > > With respect to your "Some linuxes don't use standard jre(s) ..." , and > that brings a resounding WTF? As in WTF are you blathering about? > Think about it... I can go to Sun and pick up any JRE or JDK for free. > Tar? Yup. Gzip? Yup. RPM? Yup. Got it? And if its not part of the Linux > version you chose to use, then who's fault is that? I mean I could go > on to say ... what are you doing that is outside of Sun's reference JRE? > > In short. get a friggin clue. You're starting to sound like Serge. Thanks for the compliments. Meanwhile, drop down from the cloud: http://en.wikipedia.org/wiki/Free_Java_implementations "Free" linuxes have used different components to avoid the non GPL portions of JDK/JRE. And this compoments aren't exactly the same, and don't have the exact behavior of the "classic" JRE. You can use the one you have installed or ask the installer to use the bundled one. If that doesn't work that we can consider something is wrong with the installer and that should be investigated. For more info search more or less recent threads here. Regards.

Clive Eisen wrote: > On 05/01/2010 15:06, RedGrittyBrick wrote: > <snip> >> Fresh faced enthusiastic IBM Intern: "A single Java app works, without >> recompilation, on Unix, Linux, MacOS, Windows etc. Write once, run >> everywhere!" >> > Typo > Not a typo, otherwise the narrative wouldn't make any sense! I know what my speculated FFEII said :-) -- RGB

Thanks to everybody for their help, particular thanks to Sundar Shunmugam from IBM US for the solution that worked for me, which was: 1. Extract the .jvm.bin file manually 2. Run the installer as is with just new PATH settings that you had used in JRE extraction test. (PATH=.:$PATH; .jvm.bin) 3. . Let the installer use the extracted JRE. How to do it? a. update path to include the directory For. example: export PATH=<your jvm.bin file extracted path>/bin:$PATH b. Test its effective by running the command which java (should report <your jvm.bin file extracted path>/bin/java) c. Run the installer w/o "javahome none" (w/o quotes) switch. It should use the extracted JRE. It all looks a bit odd - still get some Java class messages - but it works. Sundar also points out that the Linux distro I'm using (CentOS) isn't supported. A bit odd that it doesn't work as it's supposed to be a clne of RHEL. cheers Neil

> From: neil.truby@ardenta.com > Sundar also points out that the Linux distro I'm using (CentOS) isn't > supported. A bit odd that it doesn't work as it's supposed to be a clne of > RHEL. > It is and it isn't. The Centos Distro is a bit light and doesn't have everything in it that you find in RedHat. So while the core (kernel) is the same, there are some pieces missing. But to your point, you are correct that CentOS should work as a replacement for RedHat. With respect to 'supported' its true, its not a supported distro. If this is a commercial (production) release, you're better off paying for a commercial release that has support, like RedHat and/or SuSE. Seriously, an hour of your time is more expensive. If not, then you're selling yourself short. ;-) HTH -G _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/196390707/direct/01/

There might be an easier way. Had the same problem on HP-UX 11.11. Method 1: In you PATH is a path to java which is installed on the node. Remove all paths to any java on your node from the PATH. Run the ids_installer, it will use the java that comes with the product. Method 2: run the installer with option "-javahome /tmp" Both methods worked for me. Peter Neil Truby wrote: > Thanks to everybody for their help, particular thanks to Sundar > Shunmugam from IBM US for the solution that worked for me, which was: > > 1. Extract the .jvm.bin file manually > 2. Run the installer as is with just new PATH settings that you had used > in JRE extraction test. (PATH=.:$PATH; .jvm.bin) > 3. . Let the installer use the extracted JRE. How to do it? > a. update path to include the directory > For. example: > export PATH=<your jvm.bin file extracted path>/bin:$PATH> b. Test its effective by running the command > which java (should report <your jvm.bin file extracted > path>/bin/java) > c. Run the installer w/o "javahome none" (w/o quotes) switch. It > should use the extracted JRE. > > It all looks a bit odd - still get some Java class messages - but it works. > > Sundar also points out that the Linux distro I'm using (CentOS) isn't > supported. A bit odd that it doesn't work as it's supposed to be a clne > of RHEL. > > cheers > Neil