PDF VERSION PRINTER FRIENDLY VERSION NEWSLETTER ARCHIVES
  
 Volume 15, Number 2 May, 2005 Winchester, Virginia  


User Can Set Configuration Choice In Shortcut in the "Target:" Line

Execute / Read Only Bin Folder Requires
Moving Comname & Unibase.ini Files

Caret (Cursor) Size and Shape Can Become More Microsoft Looking

Unibase by DMAC / Unibase Imaging (Evaluation Version)
Answers a Question

Microsoft Changes a dll; Novell Must Change Too

Microsoft Terminal Services Compatibility
Dictates Unibase Changes Under the Skins

What Occurs Once in 45 Minutes?
How Does One Find Such an Incident?
What Do You Do When You Find It?

All Record Formats (Templates) Are Numbered in Sequence - Right?
Wrong!

"Red X" and "File|Exit" Now Terminate
Unibase by DMAC / Unibase Imaging

Big Brother Wez_edit Adds Some Little Brother Features

"Links of Interest" Added To www.dmac-unibase.com

Version 8.1 Comes Out With A Bang -- Microsoft Installer

Ace Contact Manger by DMAC Moves
Towards the Unibase Reliability Level

User Can Set Configuration Choice In Shortcut in the "Target:" Line

Unibase by DMAC and Unibase Imaging give the user several hundred ways of modifying the Unibase environment. All these choices can be specified in Unibase environment variables. Then these variables can be grouped into named environment configurations.

From now on Unibase allows the shortcut to specify in the "Target:" line the name of the named environment configuration.

For example in the "Target:" line the statement is entered as follows:

"c:\program files\dmac\unibase\bin32\menu.exe" -UNICFGFRED

means that when executed the shortcut will access first the COMMON configuration group then the configuration group FRED in the unibase.ini file for setting up the environment.

Clients requested this feature to replace the batch file scripts. For those who wonder, yes, the information after the name of the program to execute in "Target:" is the command line information. Any command line information can be used here in a shortcut. #

Execute / Read Only Bin Folder Requires Moving Comname & Unibase.ini Files

Now Unibase by DMAC / Unibase Imaging knows it has to look for the comname and unibase.ini files. As the HIPPA (Health Insurance Portability & Accountability Act of 1996, Public Law 104-191) and the Sarbox (rhymes with Tarbox)(Sarbanes-Oxley Act of 2002) are interpreted by various organizations, Unibase by DMAC and Unibase Imaging change.

The latest requested change is that the bin folders (directories) can be set read/execute only. Two files -- comname and unibase.ini had to be moved. After lots of discussion and experimentation, these two files took a second home in the folder before the ETBIN folder. This folder is normally the ETROOT folder -- but not always on older systems. Unibase by DMAC and Unibase Imaging look in the folder before the ETBIN folder for these two files if they are not in the ETBIN folder or if the ETBIN folder (not just the files in that folder) is set "read only."

DMAC changes the Unibase environment to support all the latest security and interoperability thinking -- if we can. #

Caret (Cursor) Size and Shape Can Become More Microsoft Looking

Little things make the world go around. Recently the cursor in Unibase by DMAC and Unibase Imaging (technically called a caret in the Microsoft world) grew to allow adjustment in two dimensions in the unibase.ini file. In addition, the default caret now is a straight line at the left of the current character space -- just like the default caret in something like Microsoft Word.

As the people in data entry from the 1970's and 1980's disappear from data entry, Unibase by DMAC and Unibase Imaging must appeal to the newer crowd of data entry people.

DMAC rarely drops a feature by choice. Yes, we still update the 16 bit version of Unibase by DMAC and Unibase Imaging. But DMAC plans to keep adding more modern features as fast as possible to the 32 bit MUI (Menu User Interface) and GUI (Graphical User Interface) versions.

If DMAC's users adjust to these little changes as they occur, one day they will be "totally modern" or as Fred thinks they now say "totally awesome." #

Unibase by DMAC / Unibase Imaging (Evaluation Version) Answers a Question

Sometimes feedback comes from the strangest places. DMAC last October, 2004, put up a new downloadable evaluation version of Unibase by DMAC / Unibase Imaging on the web. This evaluation version is the first to install with Installshield X and Microsoft Installer.

In the six months just passed DMAC learned what some potential users and current users did not like about this install. So, since it is just an evaluation version, not a production version, DMAC is going to change some basic concepts in the install and put up a new evaluation version in May, 2005, which does not provide a pretty upgrade path for the evaluation version of October, 2004.

Seems logical. If a user wants an upgrade path, they should purchase Unibase Imaging and/or Unibase by DMAC. Besides, the install is not "broken"; the final folder layout is just ugly and has meaningless duplication.

Of course, a potential user can download the newest evaluation version. If you download the newest evaluation version and already have an old evaluation version installed, you should probably uninstall the older version manually first. Since Microsoft uninstall doesn't delete all the folders/files, you may also want to delete the folder "DMAC" and all its sub-folders from the "Program Files" folder. Or else Microsoft will help you scramble the evaluation versions when Microsoft automatically uninstalls for you. The new evaluation version will work on top of the old evaluation version. The install will look strange with several folders (directories) which do not make much sense.

The directory (folder) structure in the evaluation version has reverted to the directory (folder) structure of the production version of Unibase by DMAC / Unibase Imaging. This means that the etroot and the etbin folders have disappeared.

Yes, once again you have to install the etbin folder contents ( bin and bin32) under an ETROOT (usually Unibase). Don't worry, Microsoft does it for you. But once you accept this limitation, you can have multiple ETROOTs as in the production version.

Since the installation is almost totally automatic, and since current users want to be able to upgrade an evaluation version to a production version just like before, this change fits the bill. It may not be 100% what Microsoft would do, but it works well.

And of course it supports the new Unibase by DMAC / Unibase Imaging (Production Version), release 8.1, which installs with Installshield X and Microsoft Installer. This final release of version 8.1 will introduce current users to the Microsoft world of no question installs.

See the article on Unibase by DMAC / Unibase Imaging, version 8.2, to see what is coming this fall in the next release after the May, 2005 release. Change never stops, does it?

All of these subtle, and not so subtle, changes occur because DMAC wants to be a Microsoft certified independent software vendor. This means we play by Microsoft rules.

By the way, DMAC wants its products to run under Microsoft Terminal Services too. Not sure this discussion has anything to do with terminal services, but being installable automatically by Microsoft Installer has everything to do with Microsoft Terminal Services. #

Microsoft Changes a dll; Novell Must Change Too

All software vendors must respect changes required by operating system changes. Recently, DMAC learned that calls to the ez_edit editor produced an error message about a missing service in a Microsoft dll (dynamic linked library) when using a Novell server.

First, DMAC isolated the cause of the error (DMAC calls it a bug). The bug came from the interface to the operating system -- but only on Novell servers. Searching the web, DMAC found that in February, 2005 Novell changed its download of the Clib interface which DMAC uses to access Novell server functions. When DMAC upgraded the Clib which ez_edit uses to access Novell servers, DMAC found that the changes actually occurred in code dated October, 2004.

So now in the latest Unibase by DMAC / Unibase Imaging version 8.1 release, all of the Novell dlls have changed. The new dlls have the October, 2004 date -- but they are brand new to Unibase.

Of course, the change fixed the error message. What was the error? No one at DMAC knows. We suspect Microsoft eliminated a call to a dll. Novell had to change because it used that call. So DMAC upgrades when the operating system environment changes and fixes what problems such upgrades create if it can.

Recently DMAC has been asking clients if they are using "Windows Update Service." It the client is not totally current with "Windows Update Service" we at DMAC try to help -- but many times cannot. DMAC clients need to stay up to date with their operating system fixes in order to run with the fewest errors and abnormalities.

Issues like that described above are why DMAC is working to become a Microsoft Certified Independent Software Vendor. As far as processing data, we all (hardware vendors, Microsoft, [and Novell for Novell users], DMAC, and DMAC clients, and DMAC client's clients) depend upon each other to do the best we can in our area to provide a reliable environment for data entry. We live in an interdependent world today. #

Microsoft Terminal Services Compatibility
Dictates Unibase Changes Under the Skins

Most existing Unibase by DMAC / Unibase Imaging users know the saga of WebBase by DMAC. WebBase by DMAC, version 1, was too difficult to use and too slow.

So, this year WebBase by DMAC, version 2, arrives. This WebBase by DMAC will run under Microsoft Terminal Services on a Windows 2003 Server and most likely will run on Citrix servers. In fact all of Unibase by DMAC and Unibase Imaging are changing so that WebBase by DMAC, Unibase by DMAC (16 bit and 32 bit) and Unibase Imaging (16 bit and 32bit) can co-exist on the same server and access the same persistent data.

Microsoft Installer, under the skin of Installshield X, will handle the install process. Not easy. But, two changes under the skin will happen.

First, in the last release of version 8.1 and all following versions the comname file incorporates the computer name and the Microsoft logon name. This means that Unibase by DMAC /Unibase Imaging creates a unique ttyname ( used in user variables, etc.) based on both these items. This is necessary for Terminal Services.

Second, Universal Naming Convention will be used for path names in the unibase.ini file in the 8.2 version. This means in addition to the drive letter designation (for 16 bit versions) paths, UNC paths (which are the preferred method supported for the 32 bit versions) should also be designated. Both appear in the new unibase.ini file separated by a semicolon. UNC paths are absolutely necessary for WebBase and Terminal Services support. UNC names are being supported throughout the Unibase Environment. But users will be testing all possible cases -- not just the ones DMAC wishes to test. More change is coming. #

What Occurs Once in 45 Minutes?
How Does One Find Such an Incident?
What Do You Do When You Find It?

If you are looking for a needle in a haystack you can burn it down and sift through the ashes. On computers it is not so easy.

This past month, DMAC and a valued client were looking for an "Abnormal Termination" (in the old days it was called a "Ab End", or GPF, or JO1, or fault , or incident, or even a "bug"- you choose your expression) which only occurred after about 45 minutes of keying a batch in Unibase Imaging. Of course sometimes you would get a "Send - Don't Send" message. To DMAC this means it is a Microsoft problem. But sometimes you would get a "dei.exe has failed" message. This means that it is a DMAC problem. And finally you just get a "hang" where you must "Red X" the batch. This is just plain ugly.

Of course, the trail of the bug crossed many red herrings. For instance, when one user fails, soon other users fail. This was traced to everyone starting the shift at the same time.

After much joint client and DMAC effort, the bug traces to something in the operating system environment. In Unibase Imaging the bug always creates the first symptom while the Microsoft Listbox control is used. Fortunately all three DMAC Unibase threads are "resting" at the time. So DMAC calls the bug the Microsoft Listbox error.

All the king's men (at DMAC) and all the king's horses (?) could not put "Humpty Dumpty" together again. No way could we at DMAC recover from this symptom. So now DMAC has a window appear and say "An error has occurred from which Unibase Imaging does not know how to recover. Unibase Imaging is now going to close." And Unibase Imaging does close after logging out the keyer and interrupting the batch. When the keyer logs back in the bug is gone.

Will this occur on all versions of Microsoft operating systems? Will it finally disappear in later Microsoft releases? Who knows. At least, thanks to the great help of a Unibase Imaging client, you receive a humble message which is DMAC's best effort to date. And now we know why other software products say "we have to close" rather than recovering from an error. #

All Record Formats (Templates) Are Numbered in Sequence - Right? Wrong!

An AID Generator automatically creates a structured field edit or output edit for you from your record format (template) information in a standard job. All you need to add are your peccadilloes.

In the past the AID Generator assumed you wish to have your record formats (templates) numbered in order. This was a bad assumption. Holes in the numbering of templates can occur. Even though in the standard job you relate a number to a template name, sometimes a hole in the numbering sequence makes sense.

So now in Unibase by DMAC when the field edit or output edit AID Generator encounters a hole in the numbering sequence, the hole is correctly utilized in the generation of the edit. Progress comes on small cat feet. Or is that fog? #

"Red X" and "File|Exit" Now Terminate
Unibase by DMAC / Unibase Imaging

Unibase by DMAC and Unibase Imaging, Release 8.1, previously reported to users "You have Aborted From Unibase by DMAC" whenever the "Red X" or "File|Exit" options activate. Users are unhappy because they must be unlocked and the user's batch must also be unlocked before either can be accessed again.

Ok, so the aborted message was a carry over from the past. Now the "Red X" and the "File|Exit" truly allow the user to exit gracefully. The batch is marked as "Interrupt." The user is logged out of Unibase.

What about ez_edit, wez_edit, drun, and the 100 other executable which can be spawned (run or executed as you please) from the Unibase environment? Some probably do exit correctly, some probably do not. Let us at DMAC know if you find a spawned program which does not terminate the way you wish it would.

The only rule we at DMAC can implement is --"Do what the client wishes. And if we don't know what is wished -- ask. " DMAC is asking; if multiple answers appear, environment variables will be set up. #

Big Brother Wez_edit Adds Some Little Brother Features

Wez_edit (pronounced weezy edit) is a Unibase environment text editor which allows users familiar with the older ez_edit to move rapidly to the word of graphical user interface editors. Most features of GUI text editors are present. Everyone happy? No!

Some features from ez_edit disappeared -- but now they return. Line wrapping and line numbers are two such examples of the returned features. Maybe soon most users will find wez_edit as easy to use as ez_edit. Maybe... #

"Links of Interest" Added To www.dmac-unibase.com

Several clients have requested that DMAC provide a link to their web site. Now DMAC can provide a link to a web site from its web site page -- "Links of Interest."

For now DMAC has the following categories:
1. Service Organizations who can provide work using Unibase by DMAC / Unibase Imaging.
2. Data Entry Operators looking for work using Unibase by DMAC / Unibase Imaging.
3. DMAC's other products and DMAC suppliers.
4. Unibase by DMAC /Unibase Imaging consultants available to assist in the use of Unibase by DMAC / Unibase Imaging.
5. Other links.

All DMAC wishes in return is a reciprocal link. DMAC has several logo / link buttons and/or a simple write up about Unibase by DMAC as ready made choices for the reciprocal link.

DMAC receives dozens of requests for information about those knowledgeable in its data entry products each year. Hopefully this "links' page will fulfill a need.

If you are interested in a link, please contact Tina Kay here at DMAC. You can contact Tina by using the contact button on the links page or the contact button on the support page.

Version 8.1 Comes Out With A Bang -- Microsoft Installer

Who ever heard of the final release of a version being with a new install program? Well, Unibase by DMAC / Unibase Imaging in the final release of version 8.1 has a new install program, Installshield X with Microsoft Installer.

DMAC wants to switch to a new install program. But DMAC does not want problems with the install program to reflect on a new version of Unibase by DMAC / Unibase Imaging.

So while version 8.2 is going into final Alpha test on the new servers, DMAC dreamed up doing the final release of version 8.1 with a new installer. Hopefully the only change DMAC will be verifying is that the new install can do everything the old install did.

For DMAC, this is hard because the old install asked a bunch of questions. The new install only allows the installer one choice -- the root ETROOT directory for Unibase by DMAC. Everything else is automatic.

And if you do not choose your own ETROOT, then the default is c:\program files\DMAC\unibase. To activate Unibase by DMAC in the new environment, you use the GUI version and choose to register. Times change. #

Ace Contact Manger by DMAC Moves
Towards the Unibase Reliability Level

Almost everyone knows the Unibase by DMAC / Unibase Imaging environment is extremely reliable. Most clients know DMAC acquired nine new products during the recession. All of these products use databases and have simultaneous multiple users.

Those who have had to listen to Fred Tarbox know that he feels all the products complement each other in that they use the same basic program skill sets. Fred calls it his asparagus patch.

One of the nicest emails arrived this past week praising the improved reliability of Ace Contact Manager. The email stated that Ace Contact Manager, the best network based, secure, multi-user contact manager, now is a much better product since DMAC started growing it and improving its reliability.

DMAC's Tina Kay now says it is the best contact manager (sales call system) DMAC has used. That is saying a lot because in the 1990's DMAC's sales call system was written using Unibase by DMAC. In the late 1990's DMAC tried several "market leader" products which were not sufficient.

We at DMAC think it is because the Unibase environment philosophy is shoring up Ace Contact Manager. And the knowledge transfer is not in just one direction. DMAC's Unibase development team is learning a lot about using other's controls, etc. in Unibase.

If your organization needs a good, secure, network based Contact Manager, you should try Ace by downloading Ace Contact Manager from http://www.goace.com. #