Informix Software Inc produce the Relational Database Engines, and associated programming tools that are generically labeled "Informix".
Informix Software Inc 4100 Bohannon Drive Menlo Park CA 94025 USA The main switchboard number is: +1 650 926 6300 or: Informix Software, Inc 16011 College Blvd. Lenexa, KS 66219 phone: 800-438-7627 (Sales) or 800-274-8184 (Tech.Support)
E-mail:firstname.lastname@example.org Tech Support:email@example.com
Informix employees and the Politically Correct say "InFORmix". Humans tend to say something closer to "Infor-mix". An American accent is part of the key to the first pronunciation.
Informix sells products in 3 broad categories:
These are raw database products capable of understanding SQL (Structured Query Language) commands. You need these to add change and delete records in a database, but they won't let you do any terminal I/O.
Standard Engine (or just "SE")
Available in six versions
A cut-down version of Online DSA. The differences between the OWS and DSA is that WGS does not support table fragmentation, PDQ and Continous Data Replication. These features would not normally be required in workgroup environments. If it is an Enterprise environment then DSA is recommended. OWS does not support more than one CPU VP hence parallel processing is very limited. Also only one instance is officially supported per machine.
Administration has certainly been made easier in WGS. Also Netscape FastTrack Server, Netscape Navigator Gold and Informix client connectivity are bundled in.
A version of Online which support Massively Parallel Processing (MPP) machines. These are machines where memory is not shared between all the nodes e.g. NUMA architectures and clusters of SMP machines. The most expensive and potentially fastest version of the engine as it runs on the biggest hardware. Mere mortals are not likely to see it.
firstname.lastname@example.org (Matt Bentley) writes:
Informix XPS was based off of Informix ODS 7.11 source code. Many of the features that have been added to the 7.X family have not been incorporated into the XPS code stream. Also, there were many OLTP features that were intentionally left out. XPS, in its current version is designed for DSS applications, so functionality like stored procedures and triggers were left out. There are also some SQL deficiencies. The default page size in XPS (8.x) is 4K.
On 11th Mar 1999 email@example.com (Steve Wenzbauer) wrote:-
Distributed query capability (sometimes referred to as istar) is not yet available with 8.x. As luck would have it, I had the opportunity to meet with the VP of development for datawarehousing products with Informix this week. I asked him about this same topic. He indicated that istar will only be partially implemented in 8.3 (which they are now calling Yellowstone) it will be available around September of this year, it probably won't be fully implemented until 8.4 (Independence), which they are targeting for spring of 2000.
Essentially what this means is that with 8.x you can only access data within the same instance and you can't access 8.x data from an outside instance.
A merge between Online DSA 7.x and Illustra. Supports Datablades and is the latest edition to the range.
A merge between Online DSA 7.x and Illustra. Supports Datablades and is the latest edition to the range.
These are the products which let you build a user-interface to the data held in your database (see 1.4.1, above)
These are the items which let you connect your PC to your Mini to your Mainframe, and have them all share data happily. Note that these now come bundled with Version 6.0 (and above) of the engine.
On 6th Jan 1999 firstname.lastname@example.org (Rob Zook) wrote:-
Connect consists of the run-time libraries of the embedded sql tools. Specifically, I-Connect 7.2X consist of ESQL/C run-time libraries, and message/configuration files; while I-Connect 2.X consist of the Client SDK run-time libraries, and message/configuration files.
With Informix products prior to 6.0 we had products called NET and STAR, which were used to allow SE or ESQL/C (NET) clients, and Online (STAR) engines to make network connections. These products were sold seperately.
In 7.2X, and 7.3X engines on UNIX, the ESQL/C 7.2X run-time libraries come with the products. In 9.1X engines on UNIX, again only the ESQL/C 9.1X run-time libraries are included.
So mainly you'd need Connect 7.2X if you wanted to run your ESQL/C program on a machine which didn't have any other Informix products. Likewise you'd need Connect 2.0X if you wanted to run a 9.1X esql/c program, or a OIJ, OIC++, or ODBC application on a machine with no other Informix products, or if you needed to run an OIJ, OIC++, or ODBC application on a machine that had an Informix 7.2+ engine but no version of the Client SDK installed.
See 1.4.1 (above)
"Turbo" was the original name of the Online product, so people who talk about it are either running old software in their machines, or old software in their minds.
The original version of the 4GL compiler took the 4GL source code and generated C programs, which were in turn compiled by a C compiler. Because this could take a while Informix introduced 4GL-RDS (RDS=Rapid Development System) which featured a compiler which generated P-code rather than a "real" executable. Both require a runtime license.
Will Hartung - Master Rallyeist (email@example.com) adds:
The advantage of RDS is that the programs tend to be smaller, so if you are running several DIFFERENT programs simultaneously, you get the benefit of the smaller core size.
However, if you have several people running the SAME program simultaneously, then RDS quickly becomes a limitation and a can in turn be a real pig.
Where the trade off occurs is how much of the image that the UNIX system can share across users. Running RDS, only 'fglgo' can be shared, whereas running a .4ge, most of the application can be shared.
Let's take a large maintenance program for an example. Let's say that the .4gi of this program is 1MB, fglgo takes .5mb and the .4ge take 2.5MB. (The .4ge can vary widely, especially on the RISC boxes). We'll assume that the 4gi and 4ge are the same program, and whatever local dataspace is required by the program (global variables) is washed from our equation, since they'll be the same.
if three people run the 4gi, then you've got in memory:
Now, if three people are running x.4ge, you really only have one copy in memory, with the .text of the entire app being shared, for a cost of 2.5MB (the size of the .4ge).
However, if you have 3 people running 3 DIFFERENT programs (all being the size above), then with RDS you have a total memory being consumed of 3.5 (like before), but the .4ges suck up 7.5, because they are all unique routines (yes, shared libraries will affect this, but you get the idea).
So, what happens in a lot of systems, is that there are several people doing data entry with one or two programs that they live in most of the day, whereas the back office folks are running random reports and maintenance routines with little regularity. What seems to work out best is to use C4GL on the large data entry programs that are used by several people, and leave the rest with RDS, since they won't benefit from the sharing.
We had an R/S 6000 that went from swap hell to sing-song performance by compiling one program, in a system of over a hundred programs.
Now, none of this is black and white, cut and dried, but it does seem to be an effective process in balancing system resources, and seems to generally work.
4GL for Windows and 4GL/GX are products which take standard 4GL programs (which are character based) and attempt to give them a GUI look 'n feel.
4GL for (Microsoft) Windows adds a nice GUI development environment but the end product doesn't really compare well with native Windows products (like Hyperscript or, presumably, NewEra). 4GL/GX does the same job for X-Terminals, although I'm not sure if it comes with a GUI development environment.
All are RDS derivatives and therefore can be used with the Integrated Debugger (4GL/ID)
These are different products. See 1.4.2 (above)
bernie ryan (firstname.lastname@example.org):
WingZ 1.x contained a scripting language called "Hyperscript", but when Informix came to release WingZ 2.0 they decided to rename the product HyperScript Tools. You will still find old hacks interposing the terms WingZ/HyperScript/HST.
HST includes all the goodies in WingZ 1.x, with some general enhancements, plus:
The big differences are the SQL and array facilities - providing developers with the ability to prepare/execute cursors and manage SQL access in a more efficient manner.
(bernie ryan (email@example.com))
Datalink is a tool for processing SQL queries from HST or WingZ against an Informix database.
Incorporated into Datalink is a point-and-click series of tools which enable operators to formulate a query and to add/modify/delete data, tables and databases without knowing (too much) about the underlying SQL - sort of SQL with trainer wheels.
With Wingz 1.x, Datalink represented the only mechanism for SQL access to an Informix database. With HST, in-line SQL is also supported.
TPC benchmarks are a bang-per-buck benchmark developed by the Transaction Processing and Performance Council.
Informix usually seem to hold the TPC-C benchmark records (currently DB2 on an RS6000 though!), consequently you'll see references to TPC-C regularly in their sales literature.
Here is the full information on Informix/HP TPC-C results:
System Spec. TPM-C $/TPM-C DBMS Available HP E35 2.0 401.07 1920 Informix 5.01 1 Mar 94 HP H40 1.0 406.65 2547 Informix 5.01 7 Sep 93 HP H50 1.0 613.80 2488 Informix 5.01 7 Sep 93 HP E55 c/s 2.0 728.73 765 Informix 5.01 1 Oct 94 HP H70 c/s 2.0 1290.90 961 Informix 5.01 9 May 94 HP T500 w/ 2 E35 2.0 2145.83 972 Informix 5.01 25 Aug 94 Bull Escala D401/8 3.0 2660.03 530 Informix 7.10 HP T500 w/ 2 E35 2.0 3118.20 984 Informix 7.10 1 Mar 95 IBM RS6000 J30 w/8 601s 3.0 3119.16 349 DB2 for AIX 2.1
comp.database.informix contributors often use standard Internet acronyms as an alternative to typing: (Jack Parker firstname.lastname@example.org & Alan Popiel email@example.com)
also some particular to comp.databases.informix:
It was released to allow for the new Dynamic Server which uses a multithreaded architecture. In simple terms, it allows systems with multiple CPUs to use those CPUs more efficiently. It also introduced many new bugs. Because of the prevalence of reports of bugs, many people decided to go directly from version 5 to version 7.
firstname.lastname@example.org (Bill Raper) writes:-
Maintenance Policy Change - Informix will change their patching policy beginning with 7.23. They will not support patches long-term. Instead they are going to increase the frequency of releases in order to get patches into general release as quickly as possible.
email@example.com (Art S. Kagel) writes:-
This means that if a buffer is inactive long enough it can be degraded from HIGH priority to MED-HIGH to MEDIUM to LOW making it available for use be data that is actually a lower priority than the data it currently holds. This happens without invalidating the data page that the buffer holds so that if the page is not reused and the original page is accessed again it's priority would be restored, ensuring that HIGH priority pages have maximum possible residency.
CREATE STANDARD TABLE.... -- Default same as CREATE TABLE CREATE RAW TABLE... -- Create a table that is not logged -- RAW tables cannot have indexes or -- referential constraints Existing tables can be ALTERed to or from RAW: ALTER TABLE tabname TYPE(STANDARD); ALTER TABLE tabname TYPE(RAW);
Normally rows fetched in a cursor FOR UPDATE are locked when fetched but if the row is not updated that lock is released when the next row is fetched. Now you can specify the ISOLATION mode such that all update locks are maintained throughout the transaction:
SET ISOLATION TO DIRTY READ RETAIN UPDATE LOCKS; SET ISOLATION TO COMMITTED READ RETAIN UPDATE LOCKS; SET ISOLATION TO CURSOR STABILITY RETAIN UPDATE LOCKS;
This means, in part, that is it possible to create an outer join that returns only unmatched rows which requires a temp table and two queries using Informix syntax:
SELECT * FROM tab1 t1 LEFT OUTER JOIN tab2 t2 ON t1.id = t2.id WHERE t1.id > 1000 AND t2.id IS NULL;
Since the join condition is removed from the WHERE clause to the ON clause the "t2.id IS NULL" filter will cause the query to return all rows from t1 that DO NOT match some row in t2.
The user supplied password, in a CONNECT statement, can now be encrypted during transmission to the engine from any front end.
Newly inserted rows are not considered for inclusion in the SELECT set presented to the INSERT (avoiding an infinite loop). This was previously prohibited. The effect is the same as a SELECT into a temp table followed by an INSERT into the source table SELECTED from the temp table. There is a restriction if an EXECUTE PROCEDURE is the source of data rather than a SELECT and the procedure references the target table with a select or update statement error -360 is still returned. DELETEs and UPDATEs are still restricted and continue to return -360.
It used to return 'sample deviation' it now returns 'population deviation'. The former uses (N-1) as the final devisor and the latter uses (N).
For the latest information on Informix happenings, take a look at the "what's new" page at http://www.informix.com/informix/whatsnew.htm
On 11th December 1997 firstname.lastname@example.org (Art S. Kagel) wrote:-
QA is usually 2-4 weeks if no major problems are found...
Feeling cynical today are we? OK, QA does regression testing of ALL known fixed bugs (both those scheduled for that release and for prior releases, since the 7.1 debacle regression testing now goes all the way back to 5.0x bugs) and current correct behavior. If a previously fixed bug has returned or correct behavior is violated such that it would prevent the product from being used QA will send the product back to R&D. This is per Informix official policy as it was explained to me.
Obviously, things slip through the cracks. The known bugs in the release notes are usually bugs not scheduled to be fixed in that release but which have been verified to still exist in this release. Occassionally they are minor bugs discovered during Q&A which were determined to be of low enough impact that they did not warrant sending the product back to R&D or with minor impact but high redevelopment cost that would unduly delay release. I imagine, with the new faster turnaround on update releases, the threshhold for this decision will be lowered so that there will tend to be more of these 'minor' bugs since they will presumably be able to get a fixed version out the door more quickly than in the past, but that is just my opinion.
On 22nd June 2001 email@example.com (Madison Pruet) wrote:-
As I mentioned in one of the earlier emails in this chain - the test suite takes about a month to run. The ER test suite alone takes a week and requires multiple servers (up to 50). The release for every platform must go through the test suite.
On 20th June 2001 firstname.lastname@example.org (Madison Pruet) wrote:-
The release schedule is determined more by which beta customers we have than anything else. During the porting phase, we have to run a HUGE number of tests. So to simply get a port done and pass the test suite can easily take a month. During the beta phase, we have to focus on getting the product available according to which customers are in the beta phase. We try to include customers that will 1) exercise the new features, 2) use platforms that will tend to induce problems, 3) be able to act as a refererence account. Since we try to have a beta refresh about every two weeks, and the tests required are so extensive, it is impossible to port to platforms that are not included in the beta.
We could defer the total GA of the product until we finish the ports on all platforms, but we want to be able to get the product into customer hands as quickly as possible.
Normally Solaris is included in the initial beta because that is the platform that the engineering staff uses and thus is already ready for beta. We also like to include NT in the beta, preferably when NT and Solaris will be used in conjunction. The reason for this is that Solaris and NT have different 'endian' properties, different page sizes, and are considerably different (i.e. winsoc vrs TLI, etc...) By using those two platforms in conjunction, we are better able to exercise any potential incompatibilities. We often include HP in the initial tests because we try to include companies such as SAP in the beta program and SAP prefers to test on HP. HP and Sun tends to exercise different sides of the UNIX world (SV vrs BSD/sockets vrs TLI).
However, the need of including specific customers within the beta affects the beta platforms. With 9.1, it was very important to include SGI because a key customer that was exercising the new features in 9.1 was on SGI. For 9.3, AIX is included in the beta because we wanted to include a specific customer, so AIX will be an early GA product.
On 9th April 2002 email@example.com (Jonathan Leffler) wrote:-
In general, the version number looks like 1.23.UC4. The 1.23 is a pretty orthodox major/minor/maintenance release number except that there is no dot between the 2 and the 3. The U indicates (32-bit) Unix; alternative characters can appear in that position, including H (32-bit code for a 64-bit HP-UX platform), F (64-bit Unix), T (WinNT et al), P (Perl) and a host of others. The C is another level of maintenance release; the letters start at C and move through the alphabet. The 4 is another sublevel of maintenance release. Occasionally, you'll find more characters after the UC4 (eg UC4X2 - a second patch port of the UC4 release, or UC1A1 for an alpha-1 pre-release). And there are some other version number schemes (N123 for a nightly build instead of UC4).
On 29th March 2001 firstname.lastname@example.org (Andrew Hamm) wrote:-
Our IFX techie contact here has said:
7.31.UC5 contains 45 bug fixes 7.31.UC6 contains 92 bug fixes 7.31.UC7 contains 85 bug fixes And as for 7.31.UD1 There are over 600 bug fixes coded in this version. It is an Product Update release which also contains fixes to bugs that, due to their complexity could not be included in a normal Interim release. (eg : one criteria for a fix to be included in an Interim is that the fix must be limited to no more than 4 modules) We also only fix Priority 1 & 2, severity 1 in interims. The others get deferred to enhancement releases, hence the high number.