Windows NT to Windows
2000 And Back Again;
Pentium III To Pentium IV
And Back Again

New Video Cards Not
Rejected by Unibase

DMAC Software
To Be Downloadable
From Web Site 

Faster Indexing Or Faster
Retrieval: Can’t Have Both

Linux Survey Shows
DMAC Where To Go

Why Is Keyer Speed
Important To Service
Organizations?

Long Names For Tiff Files
In 16Bit, 32Bit,
and WebBase

ParaPort XML to ParaScript OCR/ICR Offers Easy Way To Use OCR/ICR

WebBase Next Release
Get Algorithm Upgrade

Windows NT to Windows
2000 And Back Again;
Pentium III To Pentium IV
And Back Again
  

Just this past week a client reported on the following “bug.” He wanted to set up a standalone system for maximum speed to create indexes using the best combination of software and hardware. When he installed Windows 2000 on a Pentium III, he found that speed dropped 40 percent compared to Windows NT. Running Windows NT on a Pentium IV system resulted in a 20 percent loss in speed compared to the same OS on a Pentium III.

Of course, we could think of many more combinations for him to try. But if this is a bug in Unibase by DMAC (we think not) or if the client wants us to fix this problem (we think so), then the only solution we can think of is to make Unibase by DMAC work so that the LINUX version produces the metadata in persistent files so that Microsoft can use it. In the past three years we made it so that the 16 bit version and 32 bit version of Microsoft used the same persistent files, so adding LINUX (and all of UNIX by default) is not impossible. Look for it this winter.

What will this LINUX operating system do for indexing speeds? Look for speed to increase ten times what it is in the world of Microsoft. Does DMAC know why the above Microsoft and Pentium results were obtained? No, we have not a clue.

New Video Cards Not
Rejected by Unibase
  

One day, five video cards showed up in the mail. They cost from $20 to $500 each. Each had one problem for DMAC. At customer sites, they did not work in 16 Bit Microsoft mode in Unibase by DMAC and Unibase Imaging. Naturally, most worked when installed at DMAC for testing. But one was left in a developer's machine. 

About three months later, it started failing every once in a while. Because the failure was transient, the developer could not isolate the cause. Another month went by. One day the developer came in and the failure was continuous and not transient. Bingo! The problem was found; and fixed.

So Unibase by DMAC and Unibase Imaging release 7.49i and the latest upgrade of release 7.48i, work a little bit better with a lot more video cards. What was wrong? The developer doesn't want to talk about it because it still hurts.

DMAC Software To Be
Downloadable From Web Site 
  

Unibase by DMAC, Unibase Imaging, WebBase and future products like ParaPort will soon be available for download from DMAC’s web site. In an ongoing project to make the web site as useful as possible to the data entry service industry, several additional projects are underway.

A short non-interactive tutorial for Unibase has just been installed. Tutorials in Unibase Imaging and WebBase will be on line in the near future. Interactive tutorials, a shopping cart, bulletin board and chat room are all in development.

DMAC marketing would welcome any suggestions from Unibase users on the subject of making the DMAC web site more useful.

Faster Indexing Or Faster
Retrieval: Can’t Have Both
  

Gotcha. We had a client call us up and explain to us what changing the size of the node pockets in indexing does. The Client did homework that we wished we could have accomplished. 

First, the environment variable we speak of is UBIXNODE. It can be set to indicate how many 512 byte pieces make up the node in which the index stores the pointers to the batch files. In the good old days the node size was 512. Today the default node is 2048. This makes for faster indexing. 

But unfortunately, according to client data, this makes for slower retrieval. Now, theoretically, in a well-buffered operating system, this should not be. But under Microsoft Windows Operating systems, this is truth.

Other than knowing LINUX is ten times faster than Microsoft, no one has yet run comparisons on LINUX. That is, change only UBIXNODE and see what happens to indexing and retrieval speeds. If someone has this data please forward it so we can report on it.

Then, DMAC is ready if clients are willing to learn one more operating system.

Linux Survey Shows
DMAC Where To Go
  

In July, DMAC attempted to contact all of its LINUX operating system users to hear what they had to say about Unibase by DMAC running on the LINUX operating system. Here are the results.

First, LINUX has the speed. It is ten times faster that any Microsoft product when running Unibase by DMAC. This translates into faster keying, faster output and faster system administration. In the past LINUX and UNIX systems were at a disadvantage because the upgrade path to Unibase Imaging was not clear. Now, with WebBase slowly moving through the beta stage, the upgrade path for imaging is established.

With Windows XP and its related pitfalls coming this fall, DMAC expects clients and potential clients to more carefully consider LINUX. LINUX Operating System support today is available almost everywhere. IBM and Redhat are the best known. DMAC is tested on Redhat configurations. Quality outside support is readily available.

DMAC plans several changes this fall to support LINUX. One; we hope to distribute a better installation for LINUX on Redhat. Two; we hope to learn more about printers on LINUX by setting up some network printers on LINUX here at DMAC. Three; we will move our SCSI nine track tape to the LINUX and make it work well. Four; we will configure a heavy rather than light client version of Unibase by DMAC which will use the LINUX server as mainly a file server, as the Microsoft versions of Unibase by DMAC do. The workstations will be LINUX.

Then, DMAC is ready if clients are willing to learn one more operating system.

Why Is Keyer Speed
Important To Service
Organizations?
  

Too often we talk in terms of keyer speed in a service organization as if it were the “end all” without justifying our thinking. This article gives a simple reasoning which should show the importance of keyer speed.

A typical small Unibase by DMAC client has ten concurrent user licenses. As of July of this year, one of our clients says their average hourly keyer cost is $15.50, including all direct and indirect costs. Using the $15.50 per hour and 2000 working hours per year, a keyer costs $31,000 per year.

If Unibase by DMAC software allows the keyer to produce one (1) percent more work because of its speed, then, in a year the small Unibase by DMAC client is $310 ahead for each keyer. If one shift is utilized fully, that amounts to $3,100 for the ten keyers each year. If two shifts are used, the total is $6,200 for the twenty keyers each year.

If the small client is purchasing software which will be written off (and thus justified) over five or more years, then each one percent improvement in speed is worth about $1,500 per keyer. A small shop then should be able to spend about $30,000 more (310 x 5 x20) to obtain software that gives even a one percent improvement in keyer speed. (Note: Unibase by DMAC is not the highest priced software; just the fastest software).

Are small shops measuring keyer speed with this thought in mind? No. Consider this; John Haley, retired CEO of Viking Software, wrote a white paper where he studied speeds in Excell (3200 strokes per hour) versus data entry software (15,000+ strokes per hour). That is a 500 percent (times our $310 per keyer or $150,000 per keyer per year) penalty. No wonder many small shops thrive when using our Unibase by DMAC software. 

Is keyer speed the only way to get better efficiency? No. It is just the way where every small improvement can be multiplied by ten or twenty (the number of keyers).

Long Names For Tiff Files
In 16Bit, 32Bit, and WebBase
  

Don't ask how many older versions of Microsoft are still installed on brand new servers. DMAC will never tell. But DMAC tries to accommodate users who, for one reason or another, install old stuff.

So now DMAC supports long file names for tiff files when a user installs on Windows NT clients with a NT server and wants to use the 16 bit version not the 32 bit version of Unibase. Now all combinations of servers and clients and DMAC products for 16 and 32 bit and WebBase support whatever structure of directory names for the tiffs that the service organization receives.

Regularly, DMAC is asked, “Why do so many Unibase by DMAC users use the 16 Bit Microsoft version of DMAC instead of the 32 Bit Microsoft version as clients.” SPEED is the answer. See the article in this newsletter about what dollar savings come from a one percent improvement in overall productivity.

ParaPort XML to ParaScript OCR/ICR
Offers Easy Way To Use OCR/ICR
  

Late night sessions with clients sometimes produce interesting results. DMAC's new ParaPort XML import/export capabilities offer an easy way to integrate OCR/ICR into an existing data entry service bureau's procedures without the usual large up-front investment.

Here is how it produces an XML file. 

Move from the "Advanced Processing" Menu to the "File Input/Output Functions" Menu to the "Write ParaPort XML" menu. At the "Write ParaPort XML" option, codeset, device, standard job name, and file name(s) is entered. If the image data control (idc) files are found and data batch fields are found, the empty batches can be created. From this option point on, everything is automatic.

ParaScript does the OCR/ICR.

The file on the output device is then sent over the web to the ParaScript engine. The ParaScript engine automatically processes the XML file that contains data, metadata, and snippets. The output from ParaScript is received by the service bureau and processed in reverse using the, "File Input/Output Functions" menu item, "Read ParaPort XML."

ParaScript Output Fills Data Batches.

The reading of the ParaScript file populates the data batches with the field data from ParaScript. The service bureau can then verify, update, reject/reenter or correct the data batches in the currently used fashion. No new procedures are required.
Naturally, if cost justified, the service bureau could have its own server for the ParaScript processing. Also, the process could start with XML data, XML metadata and XML mime64 format snippets coming to the service bureau rather than originating at the service bureau. 
Want to learn more about this easy way to use OCR/ICR? Contact DMAC or visit our booth (number 348) at the TAWPI 31st Annual Forum and Exposition on July 22-24 in New Orleans.
We are looking for some good beta sites (translated, that means low cost from us, but lots of arrows in the back in the world of first users).

WebBase Next Release
Get Algorithm Upgrade
  

Parallel development paths cause problems. Remember in the last newsletter where DMAC announced that the image could be on the left, top, right, or bottom? Well, when 
Rick Tarbox, DMAC's senior honor student at Tulane and founders son, picked up the changes for inclusion in WebBase; sparks flew. ICQ ran continuously between Rick and Catherine (founders daughter, head of engineering at a dot com type company) as they discussed what this old programmer had done to the new code direction. 

Rick cannot wait until he graduates and comes to DMAC full time to keep Fred straight. Rick wants Fred to work anywhere but in new code design. Fred agrees.

But, Rick is spending the summer incorporating left, right, top, bottom, full screen, two screen, etc. into WebBase. He promises that the wait will be worth it. He also promises that Fred will be able to maintain the new code while he works on even newer stuff. 

Fred, when assisting on WebBase, will be working on making the Linux version easier to load, printers will work better and so on. Fred will fix little bugs in WebBase. Big ones go to Rick. Pasture grass is also green, honest.