Early Sixties

In the EARLY 60's, B.F. Goodrich Chemical Corporation (BFGCC) acquired a GE-200 system in an attempt to automate more of its data processing functions. Systems were developed using GECOM, a COBOL like language of General Electric for the GE-200. The early compiler had a number of problems and some of the fellows at BFGCC had provided considerable insight in helping GE debug the software, and over time a good working relationship developed. When IDS became available, Dick Schubert (BFGCC IS staff) realized that this could be a powerful tool in developing on-line systems.

IDS, Integrated Data Store, was designed by Charlie Bachman for General Electric to run on their GE-635 Mainframe under their GECOS operating system. IDS for the GE-200 was a primitive data base manager. It allowed a single file only for the database and had no tools for table generation so they had to be hand coded in assembler. Mistakes in coding the tables combined with bugs in the IDS code itself were a rich source of fatal errors that caused the system to crash, several times a day. BFGCC was not able to bring up a production system with GE's version of IDS due to its unreliability.

Eventually, BFGCC offered to help debug the software if GE would have no objection. B.F. Goodrich bought the rights and converted it to run on the IBM family of mainframes and renamed it IDMS in the process.IDS for the GE-200 was written in the language of the General Assembly Program (GAP). This assembler had no DSECTS, no macros and no cross-reference. In addition, there were no EXTRN type addresses or a linkage editor to resolve them. The GE-200 had only a loader. IDS and its tables had to be assembled together to create the load module, which meant a big re-assembly taking about 30 minutes, each time you changed either IDS or the tables. Programs communicated with each other through fixed memory locations, assigned in advance and hard coded into the programs that were to use them. Jim Gilliam (of the IS staff) and his team cut the IDS assembly listing apart and studied it subroutine by subroutine until they gained an understanding of the logic used. They also realized that using second generation assembler for implementation of complex software was a loser's game. A new tool was needed.

GE had a software implementation language called WIZOR. The GE FORTRAN II compiler was written in WIZOR as well as the WIZOR compiler itself. Which made WIZOR an easily modifiable language and a new enhanced dialect, G-WIZ, was soon born. Gilliam and others re-wrote IDS into G-WIZ and so created a dependable version. A copy of the new software was returned to GE as part of the agreement. BFGCC continued to work with its version of IDS and in 1969 it was modified to handle two database files. By this time, BFGCC was now running a (sort of) on-line (more correctly remote batch) order processing system in operation on a GE-265 configuration (GE235 CPU with Datanet-30 network controller) using their modified version of IDS for the GE-200 series machines.

IDMS Name Makes Its Debut

At this point, BFG instituted a corporate policy dictating that all BFG data centers will select IBM equipment (or else) when upgrading to third generation computers. Since there were no IDS type DBMSs available on IBM mainframes, BFGCC management, after a feasibility study, authorized the development of IDMS. BFGCC was a member of CODASYL and as such, had an advance copy of the CODASYL Data Base Task Group's (DBTG) April 1971 specifications. Also, Schubert, who represented BFGCC in CODASYL, was an active member of the DBTG and thoroughly knowledgeable regarding the proposed specifications. IDMS was developed using a subset of the DBTG's specifications.

IDMS was designed and written at the Cleveland data center of The BFGCC. Most of the work took place from late 1969 to mid 1971. The project team consisted of five programmers under the management of Richard F. (Dick) Schubert. The programmers and their contributions were as follows: Vaughn Austin, IDMSCALC & IDMSINIT; Ken Cunningham, IDMSDMLC; Jim Gilliam, IDMSDBMS, IDMSIDMS, and the overall design of the IDMS system; Pete Karasz, IDMSDUMP, IDMSPFIX, IDMSRBCK, IDMSREST, IDMSRFWD, IDMSUBSC, and ISL language compiler; and Ron Phillips, IDMSCHEM.

It is without doubt that the work with IDS gave us the confidence to tackle development of IDMS. It is important at this juncture to stop and point out the facts that the only IDS source ever seen by us was the earliest version for the GE-200 and that no code from IDS has survived into IDMS. We did, however, retain the concepts of file navigation based on tables and the owner-member record relationship. Multi-file databases (DMCL), areas, schemas (DDL) and subschemas are all CODASYL concepts implemented for the first time in IDMS. The IDD was our original contribution and it was not part of the DBTG's specifications until years later. IDS for the GE-200 had none of these features and for that reason alone it could not serve as the basis for IDMS. IDMS was all new design, all new code. Later versions of IDS for the GE-400 and GE-600 series machines were CODASYL compliant implementations but they came years after IDMS.

Just what WAS ISL? Although the IBM assembler was much more sophisticated than GAP, our aversion to assembler for large-scale software implementation has remained with us. A language like WIZOR was needed for the IBM. Recall that this was 1969. "C" is not yet a gleam in the eyes of Kernighan and Ritchie. IBM is already using PL/S for writing parts of MVT and other software, but they are keeping it proprietary. We had to roll our own. The implementation language was developed with the required IBM/360 features using GE-200 WIZOR 5 as the starting point which gave the programmers a familiar syntax to work with. Coding of IDMS has begun months before there was a compiler to grind the code. The code generator part of the compiler was chopped away and new code written to produce 360-assembler source code. We ran test compiles of small routines and captured the output on 7-track tape, which the GE-200 and the IBM/360 could both read. The code was submitted to the IBM assembler and if errors were found, we adjusted the compiler and tried again. Eventually we got error free assemblies. At this point we could compile the compiler and assemble it on the 360. Intermediate Systems Language (ISL) was ready for business. For the IDMS implementation we had to make do with a primitive one-pass version, as there was no time for unessential improvements. It did the job. Later, a multi pass optimizing compiler for ISL was written to produce code for, and take advantage of all addressing modes of, the PDP-11/45. A highly optimizing version for the IBM-370 followed in 1975. IDMS and all its utilities were originally written in ISL except IDMSDMLC, IDMSCALC and IDMSCHEM.

At this point, IDMS was ready for production. The initial set of data base tables was hand coded, first in plain assembler, later using macros. The macros were also utilized in creating the first IDD in early 1971 so the schema and subschema compilers had a dictionary to work from. Once those processors were developed, the hand coding of subschema tables came to a welcome end. While the development of the IDMS software was in progress, application programmers were busy converting the components of the order entry system from GECOM to COBOL. The first production on the IBM 370/155 using IDMS was PRESTO, an accounts receivable system. TOPSY, the order entry system followed shortly and many others later. IDMS at this point = was a local mode only system.

How did IDMS come to exist outside of BFGCC? BFGCC realized that IDMS was marketable software that would find a ready audience among those who, like BFGCC, were early users of IDS but were now confronted with the need to go to an IBM mainframe. A proposal was submitted to BFG management to establish an independent business unit, the Information Systems Division, which would market IDMS and other software yet to be developed and also support BF Goodrich with its corporate data processing needs. Coding pads with the ISD logo were printed and the first edition of the IDMS User's Reference manual bore the ISD inscription as well. Promotional materials like IDMS ashtrays with miniature Lifesaver Radial tires around them were given away to prospective customers. BFGCC began selling copies of IDMS, first to a local company, then to others. The first five customers of IDMS were: ACME Cleveland Co., Abbott Laboratories, General Motors, RCA, and Sperry Rand (UNIVAC). Two more prospective customers, Boeing Computer Services and Western Electric were trying out IDMS but we never got to sign them because the roof fell in on our hopes of becoming an independent division within BF Goodrich.

Enter Cullinane Corporation

In 1969 Ben Heineman, CEO of Northwest Industries, has launched a hostile takeover attempt on BF Goodrich which failed but left Goodrich in a vulnerable financial position. Corporate management was busy keeping the Company afloat and had no time or inclination to consider a new business venture, especially one that had an intangible product that was totally unfamiliar to them. At this point it is not clear whether we were turned down in Akron or if BFGCC management scrapped the idea without asking. Since BFGCC had extensive experience in licensing many of its proprietary chemical processes, we were told to take advantage of that expertise and license the product for marketing to another company using some sort of a royalty arrangement. After some research, Jim Gilliam recommended John Cullinane and his Cullinane Corporation. Big John named Tom Meurer project manager, who hired Ron McKinney and Bob Goldman from AT&T Long Lines, and Dave Thole, a freshly minted graduate from the University of Dayton. Don Kraska from BFG Corporate, with more IBM experience than any of us, was on loan to BFGCC to help with the creation of the IDMS installation tape and to help with the DMCL implementation. Shortly after that Cullinane made their first installation of IDMS at a site we already had lined up. The rest, as they say, is history.

Since then, in 1986 BFG began its transformation from a rubber and chemicals company to one primarily involved in aircraft support systems and maintenance. The Tire Division was combined with Uniroyal's as the Uniroyal-Goodrich Tire Company. Within a year or so BFG sold its interest in the company and was out of the business it was best known for. Next came BFGCC. The Company was busted into three divisions. One sold outright, one kept as the Specialty Chemicals Division, and one spun off as an independent entity called the Geon Company. Specialty Chemicals switched to an AS400 and left IDMS around 1995. Geon went to a SAP based client server system on Digital (excuse me, Compaq) Alpha processors and completed the move of all production from IDMS in February of 1997. The IBM mainframe was removed in April of 1998. And the original development team? Vaughn Austin left BFG in 1995 and is in Technical Systems Support at Alltel's Twinsburg, OH Data Center. Ken Cunningham left BFG in the 80's, worked at various companies in the Cleveland area and is now retired. Jim Gilliam, the "father of IDMS" still works at Geon, has been an Oracle DBA these last three years and was expected to retire at the end of 1998. Pete Karasz served out his time at Geon and took an early retirement offer, have been out since January of 1998. Ron Phillips remained with the Uniroyal-Goodrich Tire Company until Michelin bought it and moved everyone to Greer, SC. Ron passed away when he suffered a heart attack while clearing his drive after a freak snowstorm. Dick Schubert retired from Geon in 1995.

The story supplied by the original Developer Peter Karasz ends here. We continue the story:

IDMS In The Eighties

Cullinane Database Systems developed the system further. The main enhancement was the addition of an integrated online component - IDMSDC. In addition to its usage as a database server to be used with IBM's CICS, now IDMS could support a complete DB/DC environment of its own. Nick Rini (R) and Don Heitzman (H) led the DC development team , who also contributed to the 'RH' in RHDC prefix of IDMS modules. With the addition of ADS/OnLine 4GL IDMS was the leader in the database market. The dictionary - IDD - became a complete online dictionary - the only active dictionary in the market that time. A datamation report dated 1984 said that 4 out of 5 new IBM customers opted for IDMS.

Rise And Fall Of Cullinet

By this time, the name was changed to Cullinet and it became the first software company to be listed in the New York Stock Exchange. It was also the first software company to hit the $100 million! This was the time IBM was reluctantly entering the relational market. "System/R" research was going on at IBM lab at San Jose quite some time. Commercially the first product was "SQL/DS" on VM (1981), probably intended for simple queries. DB2 made its reluctant debut much later (1983). Reluctant, because even IBM was not sure what it was for "DB2 was first introduced on the MVS operating system in 1983. At that time, the product› s mission was to deliver the power of the Structured Query Language (SQL) for decision support or ad hoc query applications." [SG24-5273-00 Accessing DB2 for OS/390 Data from the World Wide Web, Nov 1998] Cullinet never approved the relational model. Why should they? The DB/DC system built around the CODASYL model was a huge commercial success. Truly it was the first system to be built fully around an active dictionary - our well known IDD!

But Cullinet did a marketing blunder with the Release 10.0 of the product. That was advertising the product as relational! Recall the big IDMS/R advertisements? ASF component was the 'relational' part! ASF was built using LRF which itself was not bad as long as one restricted the usage to retrieval only (like VIEWs in relational systems). One could make a table and a builtin map and dialog automatic. But there it stopped. Database is more than a simple standalone table. Using ASF one could join two tables. But there was no way to connect a group of tables to a dailog or a COBOL program. Besides the all important 'SQL' was missing. In short, there was no real R in IDMS/R. Eventhough the other components in the group, ICMS and Goldengate were good for 1984 (Goldengate/ICMS provided the first integrated PC access to mainframe data!), the R failure overshadowed evreything! Good or bad is a different thing - one cannot claim one's product to be relational without having a relational product and without endorsing the model itslef! This eventually dragged IDMS into the discussion with Dr Codd (the infamous 12 Rules). 12 rules were not the Bible of Database Theory, but it served its purpose - broadcasting and proving IDMS/R as conforming to none of the 12 Rules! [In reality, there was no point in including IDMS into the 12 Rules discussion, beacuse IDMS was not a relational system, then. If Cullinet hadn't claimed IDMS to be relational, then Codd could not have included the product in his comparison (eg: IMS was not included in the comparison)]

Emergence Of New Players

In spite of all these, contrary to many believe, DB2 was not the IDMS 'killer' in the long term. Other players were in the field. Two mini computer databases - Oracle and Ingres - had dvided the VAX-11 market. Cullinet tried to enter this area by acquiring Esvel Inc, an offshoot of System-R research alumnae.They had relational product which was to later become IDMS/VAX. Again, Cullinet did another blunder. This time instead of concentrating on the database, the focus was on Generator, a higher level specification tool which would generate COBOL. The claims were sky high - Generator can make an application in 20 minutes. There was even attempt to given Generator on mainframe. Obviously there is no magic in programming. What VAX/DB lacked was a programmable tool like ADS. Generator failed, and VAX database, though superior to Oracle and Ingres at that time, was unnoticed by the industry. Generator followed the CASE Tools like (IEF, IEW etc) to the wastepaper basket.

1987 Userweek had a blueprint for IDMS release 11.0 with full SQL support. SQL Option was supposed to be based on the SQL Engine of VAX-DB with its optimizer written in C. This was the right direction to go for IDMS. But Cullinet management headed by John Landry & Co had other ideas. They wanted to focus on Expert Systems. IDMS was sidelined and the next Userweek in 1988, there was no talk of Release 11! What a blunder. Many who worked hard to get Release 11 left the firm. VAX Magic did not bring enough revenue. Then John Cullinane came back for a brief period and talked about Enterprise DB for MVS! That is SQL Option was to be a separate database and not part of IDMS! Well, the drama did not go further. In the summer of 1989 Cullinet ran out of money and fallen in the hands of CA. By October 1989 the takeover was complete. CA got a quality database with its 3000 customer base. With Cullinet acquisition, CA crossed the 1 billion dollar mark in revenue.

What Went Wrong During 1986-89 ?

Cullinet failed because the management of 1986-89 gave up the focus on IDMS and diverted their energy and money on totally foolish acquisitions and products.The successes of previous years were not based on marketing but on solid product line. The bread and butter had always been IDMS. But the newcomers at the helm forgot that. Instead they were probably reading the doomsday predictions of Computerworld and gave up too early on IDMS.. much too early! DB2 at this stage (1989) was a very rudimentary product. In fact, IBM's own AD/Cycle with its non-existent repository at the center was a total failure. Cullinet could have easily given System Owned indexes (instead of ASF/LRF) with SQL front end as a relational database much earlier. Still later they could have come out with IDMS 11.0 - by 1988 or latest by 1989. But time was wasted on VAX/Generator and rewarping IDMS as the Enterprise:DB. There was even a product called Expert Systems which did not sell even a single copy! Much resources were wasted on such experiments. Believe it or not, IDMS itself was so sidelined and the faith in the Generator was so emphatic that in one European Meeting, a plan to give Generator to all IDMS clients and help them to convert all IDMS/ADS applications to VAX/Generator in a short time, was even passed as reality!

ADS/+PC - A DOS Product In The Windows Age

If you are Powerbuilder User and if you think why the code looks familiar, then it is not by accident. Cullinet released ADS+/PC with a single user SQL database and ADS-like language in 1988. The product was wonderful for DOS. But by then Windows was becoming the standard. Besides Cullinet was too busy with the finanacial troubles. ADS+/PC developers all left CA in 1989 and later joined a company which came out with a successful product called Powerbuilder!

Enter Computer Associates - 1989

For CA, IDMS Clientbase was a goldmine. From IDMS's client viewpoint credit should be given to CA for completing the IDMS release 11.0 (abandoning Enterprise:DB) and releasing it as Release 12.0. This is what Cullinet should have (and could have) done in 1988! CA also acquired DBMS and the IDMS/PC. Tools are still here with us, but IDMS/PC was not so fortunate. Neither was IDMS/UNIX. VAX/DB was initially used as a foundation for the builtin database of CA-UNICENTER. On the negative side, CA failed (or rather didn't try to market) in marketing IDMS as a viable mainframe server. It seems that the whole industry was expecting mainframe to die by 1995! CA did attempt to give multiplatform solutions but the soul was not there.

Though CA released Release 12.0 with full SQL in 1992-93, there was no attempt to popularize SQL. Either CA did not know what they had (in relation to other relational systems) or IDMS's own faithful CODASYL people did not trust SQL. Whatever be the reasons net result is the same: SQL option of IDMS is scarcely used and many industry analysts do not consider (quite wrongly in fact) IDMS as a relational database.

The System R And IDMS/SQL

--- Compiled from Internet Sources - Edited and html'd by IDMS/SQL News

Now that relational databases are accepted as standard on all platforms it will be interesting to look back at the origin of SQL and relational Systems. Since Codd published the first paper in 1970 on A Relational Model of Data for Large Shared Data Banks" CACM 13, 6 (June 1970), there has been resarch going on at IBM Lab at San Jose, which was known as System-R Group. One of the pioneers was Don Chamberlin who in fact coined the word SEQUEL (Structred English Query language). Incidentally Don is still wih IBM has even come out with book on DB2 Universal Database.

There were several others working at System-R Group. Some of them worked on a prototype which was known as System_d for a while. S. Andler, I. Ding, K. Eswaran, C. Hauser, W. Kim, J. Mehl and R. Williams. "System D: A Distributed System for Availability" Eighth International Conference on Very Large Data Bases, Mexico City (September 8-10, 1982).Some time in early eighties a group left IBM and formed a company called Esvel. Later some of the employees left Esvel and joined HP, Oracle, Tandem etc. Esvel was eventually bought by Cullinet in 1986 and beacme the IDMS/VAX. This later became the basis for IDMS/SQL on mainframe.

The first commercial product on SQL was not SQL/DS as many people think. It was in fact Oracle! Orcale was influenced by System-R, but not based on System-R. As one of them original devlopers, Roger Bamford put it "In terms of System R's influence on Oracle: some ideas came from Esvel, and some of those came from System R. But the original code they'd written was really like somebody had a paper that described the language, and they had a computer and nothing else. " Oracle shipped the first product in 1979 on VM. For marketing reasons, it was called Version 2. And there was no version 1 at all.

Back to IDMS/SQL (VAX) and Cullinet. The technology from Esvel was indeed a superb buy for Cullinet. This is reflected in the news which appeared in the German issue of Computerworld in 1986. The translation reads as "Cullinet strives higher IBM compatibility:WESTWOOD - Cullinet Software Inc. wants to develop their program products further, in order to achieve a larger compatibility with the large computer often commodity of IBM. The programs are to be modified so that they can operate with the Structured Query language (SQL). Cullinet reacts IBM's (SQL) challenge ever more strongly by competiting with Big Blue. In the opinion of industry analysts Cullinet underestimated so far the effects of the IBM products on own growth. Therefore the conversion to a larger compatibility is highest priority. A first step was the transfer of Esvel Inc., San Jose, in July. The product range of this provider covers also a program, which uses the Structured Query Language, which is intended for minicomputers of Digital Equipment.

What happened later did not follow this direction.

History Of IDMS Feedback

From: "Eric Waddell" ct: IDMS History Date: Sat, 22 Apr 2000 00:50:49 -0700

IDMS/SQL Adds:

IDMS/SQL News express our deep gratitude and appreciation for Eric Waddell's comments. Here are some comments from us:

Eric Waddell's letter highlights the drama which was played in the upper circles of the company. The most important factor here is the stupidest acquisitions made by Cullinet in the later half of the eighties! All except Esvel were totally useless products! (The fact that Esvel's SQL engine went on to survive in IDMS SQL option as well as was used as the foundation database for CA-Unicenter development proves this point). Not that other companies did not have useless products. Others knew when they were lying and were clever enough to take care of the lies! In a way, though they all cheated the client base, they did not fool themselves! The difference was that Cullinet failed to accept and realize the fact that these products were only worth for marketing. You needed something real behind the scene, which was sadly missing.

Goldengate was not a bad product for 1984! It was as good as the other products in the DOS market (Lotus, dBASE,123,Symphony) and even better. Goldengate was the first product to link PC to a mainframe database in a transparent way. The LU2 connectivity allowed the PC user to look at a group of IDMS LRF records (the ASF tables and views) as a virtual disk. This was remarkable for 1984. Two things spoiled Goldengate as a PC product. It was difficult to copy. There was this 'key' business. Copying was a tough job. Products like Lotus and dBase, it was easy to make pirate copies. Ashton Tate once admitted that it was the 1 million pirate copies which helped them to make the 1 million business sales! Later Bill Gates echoed the same sentiments in the PC market when he indirectly hinted that Microsoft is less concerned about private people copying the product for home use, they were happy if no one sells the pirate editions on a commercial basis. Secondly, Cullinet didn't target the ordinary users, but only the corporate customers for the product (a mistake repeated later by IBM for OS/2 with disastrous end results). In the PC world, the popcorn users rule, the corporate follows! In any case, Goldengate did not play any role in the fall of Cullinet. So let's leave the product.

The worst product Cullinet had was the VAX-Generator. This was a pure hype. It boasted to generate applications for you within minutes! VAX-Generator took all the marketing time and resources. The sales people failed to notice the VAX database product, which was, as noted elsewhere, a System-R offshoot and a superior relational database than anything on the market at that time with the possible exception of Ingres! All the emphasis was on the Generator! It is a mystery why a leader in database technology ignored the SQL database product of VAX, especially when SQL was THE issue of the times! But then the top echelons of Cullinet was occupied by the imported people from other companies who didn't know any damn about IDMS database or any database for that matter!

The next useless product was the Application Expert on VAX. Precious time and money were wasted trying to port this rubbish to IDMS! Believe it or not there were even working versions with manuals of both Generator and the Expert Systems for IDMS! Management guys from the Generator and Expert Systems occupied the VP posts in Cullinet for too long time. IDMS was sidelined. Today we can say that IDMS never recovered from this lack of attention and positioning! This was the real reason for the fall of Cullinet, and not DB2 or Unix databases as some people prefer to believe. DB2 was a totally useless product running only on TSO/E at that time, maturing only sometime in 1993-94 with the Version 4.3! [In many cases where DB2 replaced IDMS, later Oracle replaced DB2 in the late 90s]. Unix databases were not there in the mid-eighties, they were just being born out of the original VAX products - Oracle and Ingres. As Prof Michael Stonebraker pointed out in 1996 in an Informix presentation Cullinet allowed the relational startups to prosper, in spite of enough time and warning!

Experts miss the point!

One thing which is consistent with the computer industry today is that experts always the miss the point! Experts are basing their arguments on experience, which does not make any sense in a field which is changing every day and even every second. Computer Guru and talker of the early 80s, James Martin once admitted that he completely missed the PC revolution! Today's analysts are not honest enough to admit any mistakes or misses!So if anyone believes that the fall of Cullinet was related to mainframe's fall and demise there is no truth in it. The last decade saw the collapse of companies who had nothing to do with mainframes - digital, Tandem, Wordperfect, Ingres, Gupta.... And Informix and Sybase might join the fallen list too soon. Of these the most amazing is the digital who was the pioneer in the mini computer field. Unix and C language were born using digital's PDP-11 mini machines! Is it not ironic the same Unix and related systems are the cause of the demise of digital?

Nothing comes out of nothing!

If we take the four most successful companies, we see an amazing fact! 3 out of 4 are headed by CEOs who were once technicians. Microsoft by Bill Gates who was the wizzard programmer of Gw-Basic for CP/M (or QDOS) operating system. Charles Wang of CA programmed and wrote CASORT documents for IBM mainframe, Scott McNealy of Sun is basing the success on the technical strength of Unix and Java. All this underlines one point: the technicians can beat the pure marketing guys in their own game!

Ellison of Oracle is an exception, but is compensated by the manpower usage in the company. Many think Oracle's success is solely because of their marketing! Oracle owes its success to its 1000s of technical consultants who managed to implement the sub-standard database at various sites masking the shortcomings and justifying the company's marketing claims. Oracle realized one fact very early: a database cannot be just sold, it has to be sold and implemented. A client spends at least 10 to 100 times money on programming than the original license fee of the database product! Oracle participates in this implementation - it serves two purposes: one, it helps the client and avoids faliures; two, it creates a hell of a lot revenue for the company. [IDMS's own big success in Finland in the eighties was very similar: Finnsystems (not Cullinet) sold and implemented IDMS there making it the biggest database). In short, the marketing claims were defended by the hardwork of an 'army' of technicians!!!

Human Factor is the basis!

In all these examples, one thing is emerging: human factor, not automatic tools, is the root casue of success, even when the vendor boasts the opposite! Without 'human factor', companies won't make it even if the bases product is very good! The fall od Cullinet, failure of OS/2, the failure of Ingres, even the late failure of Digital VAX are clean examples of good products not able to make it! Oracle's success story alongwith the successes of huge consulting companies like Andersen and Cap Gemeni proves the other point. Total failure of CASE Tools and traditional client-server are example of the fact that buzzword alone is not enough!