|
| |
| Volume
11, Number 2 |
Spring
2001 |
Winchester,
Virginia |
|
|
|
New
Orleans Hosts TAWPI
Work
Process 2001/Summit
Fred
Tarbox to Participate in
Panel Discussion
|
|
TAWPI
(The Association for Workstation Process Improvement) will hold
its 31st annual Forum & Exposition, Work Process
2001/Summit, in New Orleans from July 22 through July 25. DMAC
will be in booth 348, across from the TAWPI Resource Pavilion
& Cyber Café. DMAC will be demonstrating the upgraded,
hopefully out of Beta WebBase as well as some super new features
of Unibase Imaging.
On
Tuesday, July 24 from 3:00 PM until 4:30 PM, DMAC’s CEO, Fred
Tarbox will join a distinguished panel of data capture experts
in an event aptly titled, “Ask the Experts: A Discussion of
Emerging Technology in Service Bureau Data Capture.” Fred’s
segment will address the future of off-shore data capture, the
impact the Internet will have on the data capture industry and
security in Internet use.
This
program is a “must” for those who like to stay ahead of the
curve instead of playing perpetual catch-up. Visit the TAWPI
Work Process 2001/Summit page at http://www.tawpi.org/forum_and_expo/index.html.
|
|
Oh
Say Can You See;
Yep, 2000 and Me too
|
|
Most
clients know that DMAC recognizes the client and the server when
a Microsoft operating system Unibase client runs. For awhile,
DMAC let Windows 2000 appear as Windows NT and Windows ME appear
as Windows 98 in the analysis. Why not? No new bugs were
immediately apparent in Win 2000 or Win ME that had not been
present in their predecessors.
Good
times do not last forever.
DMAC now has to distinguish between NT and 2000 and 98
and ME because they now have documented bugs of their own.
DMAC’s workarounds internal to DMAC code attempt to
make these various operating systems invisible to DMAC clients
but the code depends upon telling the difference between the
various Microsoft clients. Always let DMAC know if the code says
a different client is present than you know is actually there.
When
it comes to servers; Unibase will not work if DMAC does not know
which server is supporting the environment.
If you ever run into a misnamed server, give DMAC a call
and reinstall, so that the server is properly identified.
|
|
Operator
Statistics
Programs Upgraded
|
|
DMAC
has made some changes to the operator statistics programs distributed
with Unibase by DMAC. Tech Support felt that some of the techniques used
in the old version were a bit obtuse.
The
index build programs and display/output programs still provide the same
reports. However, the totals are now staggered over two lines so that
all the digits associated with a total are displayed or printed instead
of being truncated on the left if there was not enough room to show
them. In addition, the flow of the display/print routines “gets” the
next record in sequence without removing the index for the prior record.
This speeds up processing of the reports.
The
Op Stats package relies on a datafile named OPSTWF to communicate
information such as date ranges between the index build and the report
program. In the old system, the datafile was created using the command
line program “mkdf” with a template and an initialization file.
While this works just fine, the technique is so obscure that a user
could not intuitively recreate the datafile, nor view its contents.
Now there is a record format and standard job named OPSTWF so a
user can examine the contents of this file to learn how the programs
work.
The
old package used a bat file to display the menu, accept the menu choice,
and control which programs were executed. The new package uses a
fileedit or an output program to perform the same functions. Since users
are already familiar with the AID language, this eliminates having to
learn about writing .bat files, using the command line “drun”
program, understanding the .scn file, and using “reply.com”.
Tech
Support also added detailed documentation to the Op Stats programs so
they could be used as examples of how the AID language can extract and
format useful information from Unibase data files. The new documentation
also makes it easier for a user to add report programs of their own
design to the
Op Stats package.
|
|
Unibase by DMAC, Unibase Imaging,
Release 7.48i Undergoes Version Creep
|
|
Clients
tell us to give them one new version or release a year.
They have even allowed us to keep our crazy release
numbering system. So when an articulate client comes up with a
bunch of new desirable features in the middle of a version –
voilá, VERSION CREEP.
It
all started when a client wanted to do imaging their way which,
was easier than our way. For
motherhood and against sin; what could be better?
So, now Release 7.48i is going through quality assurance
(QA) again with the following neat new features:
1.
In Unibase Imaging the image can be on the left, top, right, or
bottom of the keyed data as designated in the standard job.
2.
Advancing of the image can be specified in the standard job to
be automatic or manual. That is, the image advances at the end
of every record (old way) or when the keyer hits an image
advance key. As always, the image can advance when the AID edit
says to advance the image.
3.
The standard job can specify No Zones Needed. The entire image
is then shown starting at the upper left corner of the image.
The normal keys for moving around the image can then be used to
zero in on a particular portion of the image.
4.
To make item three work well, the standard job also allows
specifying of the magnification of the image from -9 to +9
(entire readable range). Of course the user can still zoom in or
out on the image. It
even holds its place like users expect it to.
5.
Finally to decide how much of the screen is devoted to the
image, the percentage of the screen for image can be set. The
text is placed in the remainder of the screen with the number of
lines variable depending upon font size and space available.
Columns currently are scrolled if greater than the displayed
columns are configured.
Nice
bunch of new features from a trusted user of Unibase by DMAC and
Unibase Imaging. Rick
Tarbox hopes to move them to the WebBase/LINUX version this
summer. Think of the possibilities.
|
|
Mouse Bites Developer
|
The
Developer’s manual for a particular, not to be named,
software product says, “Writing a (the anonymous product)
program for multiple operating environments requires only one
set of source code. This is an important benefit of (the
anonymous product). Since we only need to write one program
for all of our operating environments, we don’t have to
juggle multiple sets of source code, making multi-platform
development easier.” This assertion has proved to be out of
phase with reality by about 180 degrees.
Most
users know that DMAC prides itself on its multi-platform POSIX
ansi C source code for Microsoft 16 and 32 bit, UNIX and
LINUX. It is truly one set of source code creating different
object code for Microsoft platforms, each UNIX platform and
LINUX platforms. Getting there wasn’t easy, but it makes for
almost bulletproof code.
So
extending Rfmouse, written in 1997 in C++, from a single
operating environment to a different environment seemed
straightforward when the tools used for development bragged
that they made it easy. Surprise. Not so. Surely everyone has been at that point in his life where it
looks like the “bad guy wins.” So it seemed with DMAC’s
new Wizard 1.0 and Rfmouse. Try and try again, no way
presented itself to make this ANSI C++ code work in the 16 and
32 bit Microsoft environments. The developer, Fred Tarbox, had
to endure endless jibes from colleagues and customers; “The mouse ate him.”
“He’s musing on mouse.” “Why is Fred’s white
elephant called Rfmouse?”
Finally
after almost six months of continuous effort, Rfmouse began to
work in both environments from the same source code.
Catherine Tarbox and Rick Tarbox had to help. Catherine
worked on a next generation project to give Fred time.
Rick and Catherine helped redefine some of the methods
in Wizard 1.0 so they could run in a platform independent
manner. DMAC’s Debugr program was upgraded.
The C++ compilers (16 and 32 bit) were set to the
highest level of error detection to detect the most mundane
errors. These thousands of errors in supposedly error free
code were corrected.
What were the problems? All the problems came from one of
three areas: 1) message handling, 2) short and long integers,
and 3) casting of objects.
Each of these areas had to be approached from the
design point of view and fixed correctly – not patched.
Why
tell our users all this? Some concepts were learned, or
relearned, which previously had never been fully defined for
the author before. 1. You can have code written so poorly as
to be impossible to fix without rewriting. 2. Good design can
be destroyed by poor implementation. 3. A lack of rigor is
truly fatal. 4. More rigorous compilers must be developed to
rigidly enforce language design. An ambiguous language helps
no one.
So
as Wizard 1.0 and Rfmouse work through quality assurance (QA),
if they make it, then parts will be moved to a JAVA subset of
C++ to try to improve rigor and to run with WebBase.
If they do not make it through QA, new classes and
methods will be developed to replace them. A delay of about six
months in DMAC’s overall time table is the result now, with
more delays possible.
In
spite of the tremendous benefits of the successfully completed
project, DMAC developers would still like to shoot the Rfmouse
(and the forever to be unnamed development product). We’re
tired of being bitten.
|
|
Tina Kay Rewrites
Operator Statistics
|
|
Had
to happen sooner or later. In the advanced AID language
programming class, Tina Kay teaches a particular way to create
programs and solve problems. Someone always asks about the
operator statistics programs.
By today’s standards, they were pretty weird, but they
were not so weird in the late 1970's when they were written.
Fewer verbs, less structured environment and so on.
So,
Tina rewrote them to agree with what she’s teaching these
days. See the attached article to hear in Tina’s words what
she did to make the programs more modern. Such descriptions as
prettier output and more exact calculations and better
summarizing do not go far enough.
|
|
From Unibase by DMAC to
Postscript to PDF to Users
|
|
Back
in the Winter 1998 edition of the Technical Review an article
described how DMAC’s new quote system, programmed in Unibase
by DMAC, output quotes in Postscript. This allowed quotes to be
printed with graphics and a broad variety of type fonts. (Of
course, this demonstrated that any Unibase output could be
Postscript.)
Along
comes another need and DMAC’s Marketing Manager, Jon Klein
(definitely sales and marketing, not technical), adapts this
chain of output to produce PDF output so that he can email
quotes and recipients can view and print them using the Adobe
4.0 viewer. Neat eh?
Jon
downloaded the GNU public domain program “Ghostwriter” from
the web site www.yabbadoo.com.
Ghostwriter converts postscript output to PDF output. He
produced the postscript file by setting the Unibase by DMAC
device to a file rather than a printer.
Jon
next improved upon the approach by outputting forms, literature,
and brochures to postscript files from word processors, graphics
packages and other programs. Using a script file he then turned
these files into PDF files. Now he can email a picture perfect
quote, form, instructions and other documents over the web in a
heartbeat. As a side benefit, he now has all his masters on-line
so that 600 dpi copies of most DMAC documents can be printed by
anyone without use of the program used to create the document.
Another
example of ICE. (Internet Changes Everything)
|
|
Video Cards Are
Not All The Same
|
|
Video
cards do differ. To make a video card work requires a software
driver. Microsoft 16 bit drivers are not the same as Microsoft
32 bit drivers. The capabilities of a display depend upon the
display, the video card, and the driver. There are some industry
standards for the operating system/applications program
interface (API) to the video card. Such standards as VGA, VESA,
VGAX, Hercules, EGA, and CGA existed during the heyday of 16 bit
Microsoft operating systems. Newer protocols and bus
arrangements exist for the 32 bit Microsoft operating system.
Newer ones, in their turn, again await the launch of the 64 bit
operating systems next year.
Although
DMAC can only react to these incessant changes, we have a plan
to make Unibase Imaging work with all these cards, drivers and
displays running on various operating systems.
-
Video
cards that have a 16 bit driver which supports 16 or 256
colors in one of the standard modes mentioned above (VGA,
VESA, VGAX, etc.) should work with the 16 bit version of
Unibase by DMAC and Unibase Imaging. If one of the mentioned
standard modes is not supported for a particular pixel
density, then chances are DMAC’s products will not work at
that density.
-
If
no driver for the 16 bit Microsoft environment is available
as in item 1 and the user still wants to use the video card,
then the 32 bit Unibase by DMAC and Unibase Imaging must be
used under the 32 bit Microsoft operating system and a 32
bit software driver. Here the selection of the various
number of colors and screen pixel densities cannot be set in
Unibase but must be set as part of the operating system and
then Unibase conforms to those settings. If the software
driver interface to the video card does not support the
minimum Microsoft WIN32 application program interface (API)
required by DMAC (in particular BitBlt), then Unibase by
DMAC currently does NOT have a workaround.
-
DMAC
will work first on making sure that all 32 bit software
driver/video cards work with Unibase over all bus
configurations provided they support the minimum Microsoft
WIN32 API mentioned above. If a question arises; send the
video card and the software driver to DMAC and we will try
to figure out how to make the video card work. Some displays
and some video cards and their drivers are so non-standard
that DMAC is clueless as to how to make them work.
As
you can see from above, the 16 bit Microsoft environment is
being squeezed out by the newest video cards.
If you plan to remain with 16 bit operating systems
and/or 16 bit Unibase by DMAC and Unibase Imaging, then shopping
carefully for a compatible video card is necessary. There are
still plenty of these cards available, it just takes some effort
to find them.
The
32 bit Microsoft environment and the 32 bit Unibase by DMAC and
Unibase Imaging versions are approaching the 16 bit products in
speed and reliability. The browser based WebBase eliminates all
these problems for Unibase by DMAC and Unibase Imaging. Any
browser that supports JAVA 1.18 (Netscape and Internet Explorer
among others) will work correctly with WebBase and Unibase
Imaging and Unibase by DMAC regardless of the video
card-OS-display set-up.
|
|
How To Listen To DMAC’s
Training CD without Speakers
On Windows 95, 98 and ME
|
|
Microsoft
has information under product support services entitled, “How
to Install and Use the PC Speaker Driver with Windows” which
solves the problem of listening to the DMAC Training CD without
a sound card and speakers.
Microsoft’s
speak.exe contains a Microsoft Windows sound
driver that allows most WAV files to be played on the PC speaker
on most computers not equipped with a sound card. This article
describes how to find the Microsoft article and the speak.exe
file.
The
article, “How to Install and Use the PC Speaker Driver with
Windows” can be read at http://support.microsoft.com/support/kb/articles/Q138/8/57.asp.
The article includes a hot link to download the file, speak.exe.
Just download the file and follow the directions. You won’t
get high fidelity, stereo sound, but you may be able to follow
the audio on the training CD without dropping $50 or more on a
sound card and speaker.
|
|
WebBase Grows Stronger;
New Release Out in August
|
|
DMAC’s
WebBase product, which allows key from image and key from paper
within a browser on the web, will soon be out of Beta. By the
end of August, Rick Tarbox should have all the features added to
WebBase that the Beta clients have requested.
In
addition he will have reworked some of his pet algorithms that
make WebBase work. One
loop in one of the threads was too tight.
The CPU overheated and aborted.
A fan had to be added (a revolutionary solution
discovered by the ISP) and a way to avoid such tight looping had
to be devised. We had to learn how to use the “top” command
in LINUX. For those
with UNIX background this is a spin-off from the “ps”
command.
At
DMAC, we have also had to learn about security over the web.
Secure Sockets Layer (SSL), secure shell (SSH), Kerberos,
Secure Remote Password, X.509 certificates for authentication
and other security TLA’s (three letter acronyms) now have been
added to DMAC’s vocabulary. We even had our Beta web site
destroyed by hackers before we upgraded security.
The
number one question everyone asks us is, “How fast is it?”
We’re beginning to get an answer. Keying from paper using
WebBase on 56 KB modems outside of the worst four hour web
period can exceed 10,000 strokes per hour. We’re talking over
the web. Keying from image using WebBase on 56 KB modems is
about 6000 strokes per hour over the web. Keying through WebBase
running on DSL (Digital Subscriber Line) with its 750KB transfer
rate should be much faster, but we haven’t yet tested that or
DMAC’s new tunneling algorithm.
Thus
we know that WebBase will work; make money for our data capture
clients; and open tremendous opportunities to everyone involved
in data capture. We also know that it will take time for us to
learn the ins and outs of this new approach to business. Well,
we’ve all been down that road before.
|
|
|
