Re: failure due to compiler?

WStreett@shell.monmouth.com (Wilbur Streett)
16 Jul 1996 08:18:29 -0400

          From comp.compilers

Related articles
[12 earlier articles]
Re: failure due to compiler? bobduff@world.std.com (1996-07-13)
Re: failure due to compiler? baynes@ukpsshp1.serigate.philips.nl (1996-07-13)
Re: failure due to compiler? alain@phidani.be (Corchia Alain) (1996-07-15)
Re: failure due to compiler? dave_sc@csl.sri.com (1996-07-15)
Re: failure due to compiler? kanze@lts.sel.alcatel.de (1996-07-16)
Re: failure due to compiler? glew@ichips.intel.com (1996-07-16)
Re: failure due to compiler? WStreett@shell.monmouth.com (1996-07-16)
Re: failure due to compiler? grout@polestar.csrd.uiuc.edu (1996-07-18)
Re: failure due to compiler? gah@u.washington.edu (1996-07-19)
Re: failure due to compiler? ok@cs.rmit.edu.au (1996-07-20)
Re: failure due to compiler? LEEW@FS.MICROLOGIC.COM (Lee Webber) (1996-07-20)
Re: failure due to compiler? iwm@doc.ic.ac.uk (Ian Moor) (1996-07-20)
Re: failure due to compiler? WStreett@shell.monmouth.com (1996-07-20)
[10 later articles]
| List of all articles for this month |

From: WStreett@shell.monmouth.com (Wilbur Streett)
Newsgroups: comp.compilers
Date: 16 Jul 1996 08:18:29 -0400
Organization: Monmouth Internet Corporation
References: 96-07-035 96-07-052 96-07-095
Keywords: errors

It occurs to me that I have an example of where I lost a great deal of
money directly because of a compiler bug..


The only problem was that it wasn't a compiler bug, it was a memory problem
in the runtime that supported an psuedo-compiled environment.


KnowledgeMan is a 4 GL product, with datafiles with Indexes and a command
language like dBASE. I was being heavily advertized by MDBS in all of the
trade journals as a better development environment than dBASE.. I had done
a lot of development with dBASE and had gotten tired of problems with
dBASE. KnowledgeMan advertised itself as a product with "No Limits"
Unlimited database size, Unlimited Record Size, and Unlimited Memory. The
Language that KMan had was compiled to an intermediate format, and
supposedly ran faster therefore than dBASE did. Sounded pretty good, had a
$500 price tag (1985 dollars), so I bought a copy.


I spent a lot of time with KMan before deciding to switch all of my
development efforts to KMan. I did benchmarks against dBASE, did some
limited stress testing, and generally tried to find ways and errors to give
me a reason to not depend on the product. After all, I had come to depend
on dBASE and was suffering with the various bugs in secondary indexes, etc,
so why bother to switch until I was convinced that the new environment
worked and worked well. KMan worked great! It ran faster than dBASE, did
indeed seem to have no limits.. and with the minor problems that I found,
the technical support was prompt and courteous.. "This is great!" I
thought. After I made the switch, I used it as a part of my competative
sales pitch with clients. When I came up against the generic dBASE
consultant, I bragged how I had stressed tested KMan, how it was faster,
and how it did advanced things like "SQL", multi-file joins, etc. I showed
them the big ads and explained that MDBS had a huge mainframe style
database, and if the client ever got to the point that they needed a huge
database, then we'd go into MDBS III which cost $10,000, but since they
didn't need that much right now, we'd go into the $500. Made the sales
process very simple. Scare a client with a $10,000 price, offer them a
solution for $500, and then add on the consulting fees.. come in at less
than $10,000 for the entire project.. worked like a charm. This was at
during the time when XT's were just out, IBM PC's were the hot thing..


I got 6 different clients into projects with KMan.. taught KMan to my
programmers, moved my existing routines from dBASE into KMan. I preached
the gospel of KMan and became the account that the NorthEast representative
for MDBS used as a reference. I figured that I was on the way to being
rich.


One of the systems that I was doing was an Ingrediant List DataBase for
Charles of the Ritz Group.. the project had reached at final production..
They started entering records.. and the disk drive that they were using
started to develope "Disk Read Errors". Since it was on a TallGrass hard
drive, and the TallGrass drives had problems, I assumed that it was the
TallGrass drive... Patches, new drives, and the problem still didn't go
away.. (after all, it was a brand new 30 MegaByte SCSI hard disk with an
Integrated Tape Drive.. ooo.. aaa .. Bleeding Edge technology!)..


Anyway, I decided to put the entire system on my personal Compaq Portable,
since I knew that my Compaq didn't have any drive problems... one hour
later, I got a disk read error ...


I finally realized that maybe it was an issue with KMan.. I called up KMan
and was assured that there were no known problems with Disk Read Errors..
If I was getting a disk read error, then it was a problem with the
hardware.. I pointed out that I knew that there wasn't any problem with the
hardware.. so what was I supposed to think? I was also KnowledgeMan's
reference account in the NorthEast, so I did have a little pull with the
company. I had also spent $3,000 on KMan software, so I figured that I
deserved to get to the bottom of this, (not to mention the 6 clients with
projects that were paying me for working systems...)


I had just personally become aware of "Garbage Collection" and I asked
if KMan had any Garbage Collection.. Tech Support told me to use the
release keyword to free the variables on the fly.. since the modules
allocated memory on the fly, I assumed that there must have been some GC at
some point.. I had noticed with Interpretive BASIC that the system would
pause on occasion, when it did GC, but I had no way to determine if KMan
did GC, and I never saw it pause.. (This was when PC's were slow enough to
see the GC pause..) But I had never seen KMan pause.. I also asked how
much memory was set aside for this "Unlimited Memory" allocation. After
writing a couple of routines to test memory allocation, I was able to
reproduce the "Disk Read Error" by allocating a lot of memory. Aha! I
realized that the problem was that KMan didn't have any GC! I also
realized that release helped delay the problem, but didn't alleviate it.


I called and asked to speak to the head of technology, since I wanted to
know of KMan used GC, and I was pretty sure that I had identified what the
problem was. Given that I was had a little involvement with the company,
Dr. David Bartcus got on the phone. He admitted that KMan didn't reuse
memory unless the variables were released in a reverse order from the way
that they were allocated.. (there was a release keyword.. which I had never
used, since I assumed that it had Unlimited Memory access) He also
admitted that even with the release keyword, the problem didn't go away, it
was just postponed.


He then told me that when the system had used up the (JUST) 64KB of memory
set aside for instance variables, that the system would just print out a
"Disk Read Error", but that would never be a problem, since people were NOT
creating production systems on KMan, and if anyone wanted to create a
production system, then they should buy MDBS III, their production
database, (which cost more than $10,000)..


I explained to him that I was using KMan for production, and that I had a
lot of time and money invested in the product. I asked him what the
timeline was for implementing GC in KMan, since I knew that would fix the
problem. He told me that MDBS had no plans to fix the problem, and
suggested that I buy a copy of MDBS III. I explained to him that his
company was involved in false advertising, and that if I thought that the
legal system would have been able to overcome not understanding the
technology, and he had been in New Jersey rather than in Ohio so I wouldn't
have had interstate problems.. that I would sue him and his company for a
lot more than $10,000.


After getting off the phone, and calming down.. I realized that I needed to
get a technology platform that I could depend on. I was done with dBASE, I
had been burned by KMan, and I needed something that would put up forms on
the screen, accept the input, put the information into a file with
indexing.. and had a language that I could depend on. I created a Screen
handler from scratch.. decided to write the code in Compiled BASIC, since I
had no problems with the BASIC compiler.. and I got Btrieve in and used it
for indexed file access.. I figured that if Btrieve had problems, then I
would write my own indexed file system, since I had seen a couple of
articles in various trade journals..


I then explained to my employee's that we had to move away from KMan, since
it had a problem that couldn't be fixed.. (boy where they pissed.. I had
taught them dBASE, and KMan, and now I was going to teach them something
else .. One actually quit, took the client with their software.. and the
KMan problem.. thinking that I didn't know what I was doing..) (The client
came back .. )


I had pretty good record keeping going from my people, I paid my employess
$30,000 in straight salary to rewrite the existing systems that they were
developing from KMan to this simple, yet stable development environment.
That's not even counting my loss of face with my clients, loss of market
momemtum, and my time.


So KMan was not exactly a compiler, it compiled to an intermediate code and
then executed.. and the problem was with the memory allocation routines an
a total lack of garbage collection.. But I did loose a lot of money and
time.


I don't believe ads in trade journal's anymore, and I'm very jaded when it
comes to new technology. I let other people be the pioneers.. (and die
with arrows in their backs..) I deliver "State of the Art" solutions with
"State of the Practice" technology.


I remember the "Unlimited Memory" false advertising of MDBS. I remember
Dr. Bartcus.. and his cavalier attitude that if I wanted to do production
work that I should just buy his "production" database...


Wilbur


--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.