Systems librarian and automation review.
Many contracts have such a provision; it's only fair. Unlike the $50 mortgage payment dating from 1962, vendors cannot be expected to continue fixing equipment, particularly as it is growing old, without compensation. Wages rise, parts costs rise, and so, too, do prices. Undoubtedly, you programmed all these CPI increases in your spreadsheets when figuring out the life-cycle costs for your system.
Unfortunately, our contract details exactly how such a price increase is to take effect. First, the notification must be received in our offices by August 15. Second, price increases are to take place on a calendar year basis; they can't start before January 1 of any year. Third, and irrelevant this time, the increase is limited to the CPI or 10 percent, whichever is lower.
In other words, our 1990 maintenance charges for hardware will be exactly what they were for 1989. Those folks missed the deadline. Obviously, no one ever read our contract. It's a fair bet they have by now. But it's not the first time such a situation has occurred.
One year they missed by fifteen days. Then our favorite project manager called up to ask if we couldn't just sneak it in anyway. With sadness in our heart, we refused, fearful of establishing a precedent that could be used against us in future years, years like 1990.
Contracts are documents one never reads without duress. It just isn't necessary. We hadn't even pulled ours off the shelf for a year. Earlier in the life of Deep Thought, it was a permanent fixture atop our desk. But today His Highness just purrs away contentedly in that air-conditioned room, rarely bothering anyone. We've called hardware maintenance people less than a dozen times in the last year. Those times we really did need help -- immediately. And for all that, we pay about $3,200 per month in maintenance charges.
But it was a good thing we had the contract pulled out, because about the same time there came another letter from our vendor announcing a price hike of 100 percent, this time in software maintenance. It seems they had just miscalculated. It simply cost more to operate the library assistance desk than anyone had ever imagined. They were pulling in a mere $900,000 per year and spending something like $2.8 million. Obviously, something had to change. And they figured all their sites would take pity on them and pick up the tab.
Since the contract was still open to the same page, we hazarded another look. Yep! Ten percent or CPI, whichever was lower. For us, that's $700 something per month, but understand there's state sales tax and a couple of other weirdnesses thrown in. So we dumped our phone log for the last year and discovered we had twice as many calls to the phone company as we had to our vendor -- once again, about a dozen calls in the last year. And half of these were for programs that didn't work. In other words, it wasn't anything about misunderstanding the system that caused us to call.
For the other six calls, we actually desired some assistance from the desk. We wanted help; we admit that. That's five hundred dollars per call, plus long distance charges.
But let's be fair. Maintenance charges are not just for running a software assistance desk. Maintenance charges entitle you to updates to the software. As everyone knows, software is never done; therefore updates are inevitable. Our maintenance fee helps pay for further development. We collect on these payments when future releases are installed with all sorts of new features. We've been told that the next release for our software is the last release, except for maintenance releases. That's because the company is now developing software for an advanced computer, not ours.
Before we go any further, let's just clarify what "maintenance release" means. It means bug fixes for programs that don't work right. But it doesn't mean any new development, unless some programmer can sneak in an extra feature along the way. Of course, we are going to offer a small amount of advice on these issues, but you knew that was coming. The first bit of advice to you is to look over your contract. It it reads much as ours does and limits price increases, and especially if it addresses the issue of venue in the case of any disputes, and if that venue happens to be your own city or county in your own state, then get down on your knees and thank someone for that contract. Thank whoever thought of that little detail.
Our second bit of advice is aimed at vendors and concerns a method of charging for software maintenance. This depends on vendor attitude, of course, but we maintain (no pun intended) that there exist certain objective facts that can be brought to bear on the issue. We suggest that a certain percentage of all software maintenance expenses be charged off to quality assurance. If you are unsure exactly what percentage to charge, just ask your customers. They'll be glad to tell you what percentage of calls they should not be making.
Our third issue is really a query. We expect to be contacting some of you shortly to ask exactly how much you are charged for software and hardware maintenance. One of the claims made by some vendors is that software maintenance charges, in particular, are way out of line in the library field, compared to the rest of the computer industry.
We'd just like to verify that, so we've been making little trips here and there outside the library, just to see what other folks are being charged. We've been over to the county payroll department and a few other places. And we've been collecting little tidbits on prices, which we will be sharing with you in the future. Stay tuned.
We've discussed our dial-in system in past issues. We have a modem attached to a dedicated phone line to allow PC users at home to dial-in to our online public catalog. Omni magazine seemed quite proud of their future predictions, which appeared in last September's issue. One of them was that online catalogs would be accessible through just such a system by the late nineties. Sorry, it's available today, not only in our library, but in dozens of others around the country and in Canada (probably many other places, too).
To rectify this situation, we will be contacting you soon to ask for information on any dial-in system you may have. We are asking you to fill out a short survey and return it to us. We will compile the information and report back to you. Our ultimate goal is to provide a directory of online catalogs throughout the country; please help us in this.
Having said all that, we must report our own dial-in modem just broke. And are we in trouble! Dial-in users are calling the library en masse, sometimes two at a time, to complain of its absence. We knew it was heavily used, but we had no idea we would cause such a reaction if it were down for a few days. We use a CTS Datacomm 2424 ADH with MNP error correction on our line. It's a special modem that runs normally at 2400 baud and uses the standard Hayes command set. But if you have the extra MNP error correction, you can turn this feature into a buffer that allows the modem to regulate speeds.
This means a dial-in user can call in at 300, 1200, or 2400 baud. The modem will translate this transmission into the 2400 baud necessary to attach such a modem to one of our ports. When Deep Thought spews forth his pearls of wisdom, the output is retranslated back to the speed of the user. This way, you do not need separate modems and lines for different speeds.
Our latest price for one of these modems is $325 from our local supplier. Although perhaps we shouldn't talk under the circumstances, we certainly feel this method of attaching a dial-in is a good one. This modem has been on twenty-four hours a day for a couple of years, so we do not believe the modem brand itself is defective. There are several other modems which will accomplish the same thing.
PC-SIG Strikes Again
Earlier this year we were able to install the PC-SIG CD-ROM of shareware programs on a dedicated PC in our central library. The single CD-ROM contains about 1,200 disks worth of material and about 8,000 separate programs. You can get anything from the PC-Write word processor to an astrology program, all easily downloaded on a standard disk.
PC-SIG has just announced the seventh edition, this time with 9,000 programs on the equivalent of 1,484 disks. The cost is $495 from PC-SIG, 1030D East Duane Ave., Sunnyvale, CA 94086 (408-730-9291). A companion to the CD-ROM is the newest edition of their catalog, The PC-SIG Encyclopedia of Shareware (ISBN: 0-915835-14-2, $17.95,417 pp).
The programs are termed shareware, usually, and aren't all officially in the socalled "public domain." This means a user can freely copy the software, but if he or she actually finds it useful, there is a fee attached for continued use. It's usually quite small, less than $30, and it may entitle the user to documentation, free updates, and sometimes a better copy of the program.
Some of the programs are intentionally crippled so that they will not perform all their features. A typical way to do this is to prevent printing of results or prevent the user from saving results to disk. Once the license fee is received, either the user receives a "key code" from the software author, or a complete working copy of the program.
On the whole we have had great success with the system, and we would like to expand the program to include CD-ROMs for the Apple II and Macintosh computers as well. The single PC is an XT with a 20-megabyte hard disk. We hid the CD-ROM drive inside the case behind a permanent enclosure. There is one 360-kilobyte floppy, although we wish we had a 3.5-inch drive after seeing how many people are stuck with that size.
The hard disk exists largely because of the elaborate Word Cruncher software that must be installed on a disk before it can be used to search the massive CD-ROM database. Other than the batches, CD-ROM extensions, and device drivers, there is very little on the disk. We even left off FORMAT.COM for fear of being called to task for giving away MS-DOS. Users must bring in their own preformated 360-kilobyte disks.
We established an elaborate batch routine complete with virus protection to help boot the system automatically. Of course, the CD-ROM stuff was inviolate, but we suspected someone would try to invade the system sooner or later.
We weren't disappointed. Within a few months, someone decided to "improve" on our system by installing some batch routines of his own. We discovered it when a user mentioned a sign on the desk instructing him to type "START" to get to the menu. Now, we didn't put up such a sign. What was this?
On investigation we found all our batch files changed to a slightly different approach, with, we must say, no real improvement. Our erstwhile hacker hid files on disk, then left us a quite lengthy note describing, among other things, the Hacker Ethic, and how he was a benign hacker and not an evil one. He announced to us how difficult the routines were that he had installed (they weren't), but wisely neglected to leave his name. We replied with a scathing editorial on disk to stay off our system; and we haven't had any trouble since.
Regardless, we are quite prepared to entirely reformat the hard disk upon any sign of trouble. Other than this single incident, the system has run relatively trouble free. Online help is adequate, and support problems for users have been minimal.
The only downside to running the system has been the necessity of a dedicated PC and the space for it. But we can't think of an easier way to circulate software without worrying about it.
If the world were to start today, dBASE would not be dominant in the database management system marketplace for micros. We guess the winner might be Borland's Paradox as an overall favorite, with Advanced Revelation reserved for the technophiles. But back in the ancient days of CP/M, dBASE II was a cut above the competition. Originally named "Vulcan," dBASE became famous because of an ad, depicting a bilge pump, which stated that all other database systems were similar to this pump because they sucked. On such innovation, reputations are born. By today's standards, dBASE II was archaic. But back then, it was like driving a Ferrari instead of a Volkswagen. Programmers flocked to it -- not because it was a good database management system, but because it was programmable!
Indeed, dBASE is not so much an easy-to-use file system as it is a computer language, every bit as powerful as any other language. We've written a complete accounting system in dBASE. You could write a circulation system in dBASE. And we absolutely guarantee it would be easier to maintain than some of the esoteric, weirdo systems we are forced to deal with in the minicomputer world today.
To compare dBASE with some wimp file program like PFS File or Microsoft Works is like comparing a fishing boat to a cabin cruiser. It may not be fancy. It won't impress your friends with "ease of use," but it surely gets the work done.
In the inevitable slick magazine comparisons, dBASE is simply mislabeled. It ought to be compared with Pascal and C, BASIC and Ada. That it happens to manage databases very well is a very exciting bonus, not a detriment. After all, what are we manipulating with all this computer power?
That Was Then
But that was then and this is now. In today's world, dBASE always falls behind in areas such ease of use, documentation, and error handling. It constantly gets beaten by other products that have concentrated on making database systems easy to use, particularly for the novice.
dBASE has tried to do the same thing, of course, in order to stay ahead of the competition, where it still remains. But all this is done at a significant cost. The difference between dBASE III+ and dBASE IV, for example, is a mere 3 megabytes of storage. Three megabytes! dBASE III+ takes up 500 kilobytes. dBASE IV takes up 3.5 megabytes. It's got all this junk in it. It's got a poor excuse for SQL, the Structured Query Language made popular in the mainframe world. It's got so much help that it boggles the mind, bogs the system, and fills the screen with garbage extraordinaire. And it's slow. It takes forever to load. Every program written must be internally compiled. Every report must be generated. Every file must be massaged ad nauseum before the results, always unpredictable, are displayed on the screen. It's a mess, because it's trying to be all things to all people. It's trying to anticipate every potential error, every possible permutation, every conceivable instance that someone, somewhere, might think a computer can handle.
We Still Like dBASE
And after all that, we still recommend dBASE. We recommend dBASE because it's so big. We recommend it because if you were to attempt to find someone off the street to put your systems back together again, that person off the street would be more likely to know dBASE than any other system. We recommend it for the same reason we require English of our employees. Not because it's the best, but because it will ease the burden of communication.
One of the proofs of this is in the so-called aftermarket for dBASE-related products. The aftermarket consists primarily of products that augment what dBASE already does.
Some of these products fulfill the same role that grammar and spelling checkers do for word processors. They check a programmer's work. They make sure variables and subroutines make sense before they are run. They will automatically indent programs written. They will extrapolate data and make fancy graphs. They will translate from one form to another.
And some of them will compile.
Compilation is a little strange, but understanding it explains a lot, not only about the micro world of dBASE, but also about the miniworld of our integrated systems. In essence, compilation is the process by which a program written in high-level computer language (understandable by humans) is turned into a low-level set of codes understood only by a computer.
There are two basic advantages of compilation. The first is speed. This is because a compiled application results in a set of codes that can be translated by the computer into a set of instructions very quickly. There are no intermediate steps.
On the other hand, an interpreted language, such as raw dBASE or raw BASIC or any of a number of other languages, must first translate the high-level, human-like language into machine language before it can be executed. This must happen each time a line of code is read. As a result, life moves slowly. With so much going on, speed is an advantage.
Compilers Hide Code
The second major advantage to compilation is the fact that you can distribute a compiled file to a user, knowing full well that the user will never be able to change anything about the way you have written the code.
It is possible to get into a compiled file and change things around, but it is extremely difficult, even for a good programmer. The major reason for this is that the structure of the language is gone. There is only a stream of numbers, usually in hexadecimal, that mean nothing until "disassembled" into something meaningful.
This is the difference between "source code" and "runtime" code. We know that some of you do not have source code available to you at all; it's all compiled. Any change, no matter how trivial, must go through the vendor.
This means that if the post office people call you up and says you must remove a line of dashes traveling through the middle of your postcard because it interferes with their automatic barcode processing equipment, you cannot get into the file that places the dashes on the card and replace those dashes with a space.
Now, the vendor probably does not want you messing with the source code -- with good reason. If you don't know what you're doing, you could mess something up pretty badly.
Besides, the program wasn't sold to you; it was "licensed" to you. You may have thought your $100,000 was actually buying you something. Wrong. This is what made Howard Hughes rich. He didn't "sell" drill bits; he licensed them.
That's another issue, actually; we have heard some vendors say that software for libraries is severely underpriced. We heard one claim that equivalent software for the real world would cost ten times as much as it does for this nether-world of libraries. Amazing.
We have an accounting system that is in place at several libraries, a park department, and a fire department. We furnish source code. But if our friends using the program decide to change something, how can we support it? We can't.
It's not so bad if they change a line on a screen, or take the dashes out of the middle of a postcard, but if they change some program logic, there is no way we can follow what they have done, particularly when we are attempting to make all programs uniform for all sites.
The bad side of all this is that it costs us more to support a program if we insist on doing it in this manner. We have taken control away from the site -- out of fear, mostly -- and placed the entire responsibility for running the show on our own shoulders.
Libraries and librarians, of course, are not known as good programmers. By and large, we can't change the program code even if we want to. (There are exceptions, of course; we know who both of them are.)
So you can see that the issue of compilation is a little more complicated than the vendor trying to hide source code from you. There are some valid reasons for doing it.
Compilers in the mainframe and minicomputer world are part of the program, so to speak. But in the microcomputer world, compilers have taken on additional meaning. dBASE compilers, for example, are a slightly different issue, almost the opposite issue, really. Here, compilers arose not out of a need to hide or speed up the code, but as a way to circumvent the original publishers of the program.
The compilers arose largely out of the stupidity of the Ashton-Tate Corporation and its inability to serve its user population, composed largely of programmers rather than "end-users," a term we detest. dBASE became popular not because it was easy to use, but because developers (programmers) made it popular by writing applications in the dBASE language.
Before Ashton-Tate added all the bells and whistles with dBASE III+ and dBASE IV, programming was the only way you could effectively use dBASE features. Naturally, these developers wanted to sell their programs once they were completed. In order to run the programs, however, one needed to purchase the dBASE program/language itself. As a result, a potential purchaser got hit twice: once for the application program and once for dBASE.
But the developers figured Ashton-Tate didn't own the dBASE language. They claimed it was in the public domain. Besides, it was the developers who figured out how to use it and added their own features. It was the developers who made dBASE fly.
Ashton-Tate, on the other hand, not only claimed ownership but made it increasingly difficult for the developers to market their wares. Ashton-Tate developed a so-called Runtime package that developers could buy for a hefty price, allowing them to run their applications on a watered-down version of dBASE. This they could distribute with their packages.
Thus Ashton-Tate was cutting itself in on the developer pie. The original Runtime sold for $150 each, five minimum. For that fee, a developer got a program disk and five fancy labels proclaiming Ashton-Tate's presence.
Unfortunately for Ashton-Tate, they weren't the only smart guys in California. Several other companies developed compilers for dBASE that were similar to Runtime, but with a couple of differences. The first difference was that the compilers enhanced the dBASE language with added features the developers had been screaming about for years.
The second difference was that the compilers were sold to developers only once. The understanding was that the developers could compile their dBASE applications and then distribute them at no additional charge.
Finally, developers were free of Runtime license fees. They could develop in the dBASE language, compile the code, and distribute their applications as stand-alone programs. Indeed, no one need ever know the application was written in the dBASE language.
A pretty serious advantage, however, was that all files written by the compiled applications were in dBASE format. And since the dBASE format was the lingua franca of data structures, the information could be translated to anything that could read dBASE. This included every other database program on the market, since they needed to be able to translate dBASE if they were ever to coax users away from the standard. That's why R:Base for DOS has better import facilities than dBASE. They have to; Ashton-Tate doesn't. When you're at the top of the heap, everyone else must improve on you.
The original compilers could compile dBASE code, but they couldn't create a dBASE file. Developers still needed to have dBASE in order to create the original files. Since most of them had been developing for dBASE long before the compilers made their appearance, this wasn't a problem.
But the compiler makers saw an additional market, and soon there existed dBASE clones in abundance. Two of the most famous include Wordtech's dBXL and FoxBase. Internally, the programs are vastly different, but they include the dBASE language syntax and they create and work on dBASE files.
They are also much cheaper. The following table shows typical mail order prices for several of these clones. Retail prices are much higher, of course, but we maintain no intelligent person buys software at retail prices. If you do, wise up. Call Egghead Software. They'll set up a corporate account for you. That way, you'll get prices almost as good as mail order.
dBASE IV $400 Foxbase+ $199 dBXL $145 VP-Info $145
Clipper and Quicksilver
The most famous compiler of dBASE code is Nantucket's Clipper, which sells for approximately $400. Wordtech's Quicksilver is another compiler for about the same price, and it is the one we use and love. Both these programs compile dBASE code so that the completed application stands alone -- it runs without dBASE.
These programs can save you a lot of money. As you might suspect, we are often called upon to help install just a "little something" on one of the machines in the library. Usually the little something turns out to be a hefty relational database application that requires something like dBASE before you can even get started.
But rather than buy yet another copy of dBASE (at $400 plus) to load onto a machine for one application, we just write the program on our own machine, compile it with Quicksilver, and install the completed application.
After doing several of these programs, it is not that difficult. That's because they all have similar routines. They all must enter data, edit data, delete data, and report on data. What else is there?
Okay, you often need to process data, but that can be taken care of within the context of the other routines, particularly on fast '286 or '386 machines, which can "absorb" indexing overhead very quickly. Plus it's nice to provide an easy way to back up data files, change printer codes, and the like, but these are standard routines that can be included within any application. They just get plugged in with the rest of them.
After awhile, it simply becomes a matter of choosing routines from your own library to assemble into a working "custom" application, just like choosing accessories for a car. And with every new system, you learn a little more.
For example, subject headings had always defeated us because we couldn't figure out how to get several fields for subject headings merged nicely into one file to print out. A real programmer might not have had this problem, but we do all this stuff with mirrors, and we had to stop and ponder.
The solution finally came to us as we were pulling together a program to catalog archaeological digging specimens for a friend. The "descriptors" for his artifacts were immediately turned into magazine subject headings for the library's magazine program. The reference department had a working magazine system in about two days. This is our scam. Use it if you want, but please don't tell.
Although this discussion on compilation has ranged over minis and micros, applications and vendors, we hope to leave you with the conclusion that a dBASE compiler could potentially help you through many database problems. It can save money and time.
Michael Schuyler is the systems librarian for the Kitsap Regional Library System, Bremerton, Washington, and co-editor of Library Workstation Report.
|Printer friendly Cite/link Email Feedback|
|Publication:||Computers in Libraries|
|Date:||Nov 1, 1989|
|Previous Article:||New optoelectronic chips enable high-speed optical links.|
|Next Article:||New technologies.|