"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis,
Starshine Technical Services, http://www.starshine.org/

Clipper/xBase Capacity Problems --- DOSemu as a Solution?

"I don't think so."

From Steven Jackson on 25 Jun 1998

Hi AnswerGuy,

I was reading an article on the web about diskless workstations and redhat when I recognised your name, (I think you helped me out with redhat a long time ago, thanks).

You're welcome.

I look after a small network of 4 pcs at a doctors surgery which runs an accounting package and an appointments diary compiled under Clipper. System Manager is run on the host pc which does all of the local processing of these applications and the clients run as virtual terminals.

I don't know what you mean by "system manager" --- from what I remember/know of dBase and Clipper these were designed as single-user database systems. The multi-user deployment of xBase applications normally relies on "record locking" (similar to file locking but allowing one to request exclusive access to a portion of a file).

In this model the .DBF files are normally stored on a network filesystem (Netware, LANtastic, and later WfW among others). I don't know if Samba or the Mars-NWE (Netware emulator) supports these forms of record locking.

It is unclear from your description how your are running this. You mention 4-PC's and Clipper (a DOS based compiler/developement package for dBase programming), which leads me to think of networked DOS systems --- then you mention "virtual terminal" which suggests that you're using a multi-user OS (like Linux).

Are you running DR or CCI's "Concurrent DOS" (or their later "M-DOS" or "Multi-user DOS") or something like TSL's "PC-MOS" (another multi-user MS-DOS clone)? Is "System Manager" yet another multi-user DOS?

Over the past year or so the system has run slower gradually to the point where it is getting annoying. I'd like to try running linux on the fileserver and somehow run the dos based clipper programs under dosemu. I think it would be wise to keep all the *.dbf files on the server rather than sending them over the network. I got the idea from the recent Linux Journal article about the Latvian Police dept.

The first question is:

Why is the performance degenerating?
 

The obvious suggestions are:

Have you been regularly "pack"-ing your databases (purging deleted records and transactions)?

Have you been maintaining your indices? (Indexing is usually a vital key to db performance).

Have you been defragmenting your filesystems regularly?

Has your system utilization increased in some marked way (you've added *lots* more customers, etc)?

Does your current design have any features or support for migrating old and inactive records to "archival" or "historical" databases (tables) so that the "active" db routines are maintained at feasible sizes?

Are there other activities on your LAN that might be causing network congestion?

Regarding the notion of running the existing program under DOSemu . . .

I don't know if that will do any good at all. Since we don't know what is causing the problem, it seems premature to recommend solutions. My first thought is that moving the processing from four systems onto a single one (even a single system under a superior OS) is unlikely to improve overall performance.

Do you have any ideas about how I could embark upon this?

Thanks,
Steve Jackson

I have many ideas. The first, and most obvious, would be to port the application to a client/server database design --- one that's designed to be multi-user and scalable at the outset. Another, less radical approach would be to take the existing Clipper sources and port them to Flagship (an xBase to C development package from WorkGroup Solutions).

... their web pages suggest that they will soon be shipping betas of a "visual" frontend for xBase programming. That should be interesting for all those "VB" and "VC++" developers that are still clinging desperately to Microsoft's platform.

Or you might try X2C from:

http://www.on-the-net.com/x2c/

The questions I asked above may give you some ideas for some "stopgap" measures (re-index, defrag, migrate inactive records, etc). In the long run you'll want to do some analysis to see if the current system can continue to meet your needs.

If you do decide to go with a client server model you have many choices that run under Linux. There are the free and shareware packages like mSQL, Beagle and MySQL and there are a number of commercial packages like InfoFlex Adabas, and the JustLogic SQL. Rather than give URL's to all of these I'll just point you at the definitive guide to RDBMS packages for Linux --- maintained by Christopher B. Browne at:

http://www.hex.net/~cbbrowne/
http://www.ntlug.org/~cbbrowne/rdbms.html

... and another excellent list of Linux business applications maintained by Linas Vepstas (NOT to be confused with Linus the kernel guy) at:

http://www.linas.org
http://www.linas.org/linux/db.html

I should mention that you aren't limited to just xBase or SQL --- there are a number of alternative DBMS system that are available to Linux and other Unix users and programmers --- including a number of object-oriented and hybrid systems. Allegedly there's even Linux support for the venerable Pick system.

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 30 July 1998

	SCOkeys	chroot	dosemu-db	NTauth	cdr	3270	comport
	lilostop	emulate	ppadrivers	database	vacation	nullmodem	lockups
	gzipC	newlook	c500	solprint	vc1shell	memleak	tvcard