We were writing DOS programs for networks long before Windows was invented.
I have written many DOS programs that work over a network just fine. In fact
many of my programs were network utilities. It can actually be a VERY
simple process. Your program doesn't "have" to know anything about
"Ethernet" or any of the ISO network layers. All a DOS program needs to
know is how to handle simultaneous writes to a single file - which is
simple. If you can specify a full path for where the logs are stored, then
you can save logs across a network - i.e. C:\TR\logs or F:\TR\logs, etc..
The difference between a network drive and a local hard drive is "invisible"
to the program. In order to support networking multiple PCs together, you
do need some type of network driver. You can even boot in DOS and use
Windows 3.x's built-in "DOS" commands to start the network services and map
a network drive. Or your can run TR in a DOS shell in any of the newer
Windows operating systems and have full network support. The bottom line is
that there are MANY ways to provide network services under DOS. Remember
that providing network services is NOT the function of a DOS application
like TR. Network services are provided by the operating system and
subsystems - not applications.
Once you have a network drive mapped, each instance of TR can be configured
to write to the same log file. The secret to supporting multiple
simultaneous writes to a single file is to have your program be patient. In
other words, if your program tries to open a file for writing, and the file
is "locked" because another program is busy writing to it, then you create a
loop that keeps trying until it successfully writes to the file. You can
also utilize a "lock" file to flag when the file is busy. You eventually
need a time out so that if the network is down, the program doesn't lock up
trying to write to the log file. In the event the network goes down, you
have your program write to a log file on the local hard drive. When the
network connection has resumed, you can reconcile the local and network log
files. I have written DOS programs (in Pascal even) that had hundreds of
PCs logging to a single file. With logging such as TR does, the file access
times are VERY quick. By changing the routines that perform the actual file
writes to loop if it can't open the file for a write, you essentially create
a network version of the program with literally a handful of code lines.
The other change you need to make is to change the appropriate file formats
to support logging of a new field which identifies which "workstation"
logged the contact.
This is the basic operation of a network logging program - perhaps a bit
oversimplified. From here, once you have a contest system on a network, the
imagination starts running wild. I can envision a separate program running
on another PC that monitors the network logs and displays real-time stats
for observers to watch. This can be displayed on a TV monitor for the larger
observation crowds. :-)
Another interesting feature for a network contesting logger would be to
include instant messaging. This feature would be nice if you wanted to send
the message "N6TR waiting for your call on 28.500" from the 20M workstation
to the 10M operator's workstation who needs the station for a mult. A
messaging function like this can be accomplished two ways. One way is to get
somewhat fancy and send live TCP or UDP packets to each workstation to
facilitate instant messaging. Another more simple method would be to
maintain a message file and each workstation would check that file by doing
a periodic read every few seconds. If there is a message waiting for the
workstation, the workstation deletes the message from the file, and pops up
the message. The latter method is simple, though not very efficient.
Adding network support to a DOS program can be fairly simple, and evolve to
include lots of additional network features. Just don't be fooled by all
the fancy Windows software into thinking that DOS programs can't support a
network. The truth is that DOS programs can be made to run on a network, and
be very stable. Something Windows programs with all their complexity often
have difficulty with.
Thanks,
Kevin.
------------------------------------------------------
Kevin Hemsley
Systems Engineer
Microserv Computer Technologies, Inc.
kev@ida.net
KB7TYA
--
FAQ on WWW: http://www.contesting.com/FAQ/trlog
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|