8/8/89 Santa Fe Institute's D O U B L E A U C T I O N T O U R N A M E N T CHAPTER 2 -- THE SOFTWARE ------------------------- This chapter describes the software available. It also explains how to obtain the software and documentation that you need, and how to start setting it up on your own machine. There are many details in this chapter, but probably only part of it will apply to you. 2.1 Communication Methods ------------------------- The first key to understanding the software is a knowledge of the communication methods that can be used between the monitor and the players. Note that in all games there is one monitor and at least two separate players. The monitor and each of the players is a complete program in itself; the players are NOT "subroutines" of the monitor. The monitor program and the player programs may run simultaneously (either on the same computer or on different ones connected by the Internet), or one at a time. The players each communicate only with the monitor, not directly with each other. The different communication methods are described below. In each case we show only one player communicating with the monitor, but in a real game there would be more. The monitor can support any mixture of communication methods that are available on the computer concerned. Certain facilities are only available to player programs based on the skeleton programs written in C. Such programs are referred to as "C players" below, and include the human interface. FILE-BASED COMMUNICATION This is the slowest communication scheme but is available on all supported systems. It is the ONLY communication method available on an IBM-PC, or on any other machine that can only run one program at a time. Suppose the the player program is called PLAYER. Then the following sequence occurs for each step of the game: --------- | MONITOR | ------------> PLAYER.IN --------- | | | \|/ -------- | PLAYER | <----> PLAYER.SAV -------- | | | --------- \|/ | MONITOR | <------------ PLAYER.OUT --------- The monitor writes file PLAYER.IN and then starts up the PLAYER, which reads it. The player writes file PLAYER.OUT, which is then read by the monitor. The monitor itself is suspended while the PLAYER is running. The PLAYER is started up separately for each step of the game, and exits after writing PLAYER.OUT. Because the PLAYER is not running continuously it must save its working variables, either in a file called PLAYER.SAV as shown, or (C players only) in PLAYER.OUT following the output messages. This communication method is obviously very disk intensive, and also involves many program launches. It is not recommended when other methods are available. On an IBM-PC it can actually be made fairly fast by placing the player programs (and thus their .IN, .OUT, and .SAV files) on a RAM disk. See the instructions below. On a Vax/VMS system it is extremely slow. PIPE-BASED COMMUNICATION This is the recommended communication method for use between the monitor and each player when on the same multiprocessing machine. The monitor and players all run simultaneously, and communicate via "pipes" (or their equivalent, e.g. "mailboxes" in VMS): --------- -----------> (stdin) -------- | MONITOR | | PLAYER | --------- <----------- (stdout) -------- There is one pipe for each direction. At the player's end these pipes are arranged to look like the standard input and output channels, which would normally be attached to the terminal. Thus the player program can use simple read and write operations without any special knowledge of pipes. The monitor program is started up first and then starts up all the pipe-based player programs. They are technically "child processes" (Unix) or "sub-processes" (VMS) of the monitor's own process. The players keep running until the end of the game or an error; for most errors detected by the monitor the offending player will be "killed". There is a modified form of pipe-based communication available only for the C players and the human player. The player uses special channels ("descriptors") for the pipes, leaving its standard input and output free for terminal communication. This is essential for the human player. This form of communication is called "arg-based communication" because the descriptor numbers are passed via command-line arguments from the monitor to the player when the player is started. INTERNET-BASED COMMUNICATION -- DIRECT Direct Internet communication is available only for the C players and the human player. It allows such players to connect to the monitor over a TCP/IP Internet communication link: --------- -------- | MONITOR | <---- Internet ----> | PLAYER | --------- -------- | \|/ display The monitor and player programs are usually on different machines at different locations. The monitor is normally the one at sfi.santafe.edu, called the Santa Fe Token Exchange (SFTE). The monitor runs at a pre-arranged time (every hour on the hour for the SFTE) and users start up their players at the appropriate time at the remote sites. The player program itself establishes the connection to the monitor. The player program can display the progress of the game to the screen (or to a file) during the game. INTERNET-BASED COMMUNICATION -- VIA DANI The direct Internet-based method described above is only available for the C players and human player. For other languages the Double Auction Network Interface (DANI) must be used: --------- ------ -------- | MONITOR | <---- Internet ----> | DANI | <-----> | PLAYER | --------- ------ -------- | \|/ display DANI acts as a relay for messages between the player and the Internet. It can also display the progress of the game as it runs. DANI and the player can communicate by any of the non-Internet methods described above (file- based, pipe-based, or arg-based). The monitor is started first (at a prearranged time), and then DANI is started at the remote site. DANI then starts the local player. DANI can only support one player at a time. DANI can also communicate with the player by some additional methods not discussed here. Please contact the organizers if you have a special need not covered by the cases presented here. Using DANI may sometimes be preferred over the direct Internet method even for C players, because DANI's display format is more compact than the C player's (which is designed primarily for the human player). 2.2 Outline of the Software Available ------------------------------------- The software available for the Double Auction Tournament consists of the following major parts: 1. The monitor. This is needed if you want to run double auction games on your local machine or network. Without it you can only play games on the Santa Fe Token Exchange (SFTE), via the Internet. This is available both in C source form and in IBM-PC executable form. 2. The skeleton players. You will certainly need one of these, in source form, if you plan to develop your own strategy (without it you can only play via the human interface on the SFTE, and cannot enter the tournament). They are available in the following languages: C for Unix, Vax/VMS, Unicos, Turbo-C, Quick-C Fortran for Unix, Vax/VMS, Unicos, MS-Fortran, RyanMcFarland, Lahey Pascal for Unix, Vax/VMS, Turbo-Pascal Using another language (e.g. Lisp, Ada, Basic) is possible for games on the SFTE (via DANI), but is not acceptable for tournament entries except by prior arrangement with the organizers. Using one of the above languages on a different system or compiler will not be difficult in most cases, though some features may be lacking. Contact the organizers for advice. 3. The human interface. This allows you to play against computer strategies, either with your local monitor or on the SFTE. The human player is available in C source form and in IBM-PC executable form. The C source actually shares much of the code of the C skeleton player and is packaged with it. 4. DANI: the Double Auction Network Interface. This is needed if you want to play on the SFTE using a player program based on the Fortran or Pascal skeleton players (or anything else but C). It may also be useful even with the C players because its output display is compact. DANI is available in C source form only. 5. PP: the simple pre-processor. This is a program that processes another program performing file inclusion, parameter substitution, and conditional compilation (it recognizes a subset of the C preprocessor directives). It is needed if you want to use the Fortran skeleton player on a non-Unix machine. It may also be useful for Pascal; see the README file for Pascal. PP is available in C source form and in IBM-PC executable form. 6. Networking software. The programs described above have only partial networking ability. The C players and DANI can contact the Santa Fe Token Exchange only, and the monitor supports only local players (on the same CPU). Only one human player at a time can play in a local game, because it needs the login terminal. To relax these restrictions, either to set up a networking monitor (your own token exchange), or to connect to a token exchange other than the SFTE, you need the full networking software. THIS IS NOT NORMALLY DISTRIBUTED FREE TO PARTICIPANTS. Contact the organizers for further information. Note that while the skeleton players are available in several languages, the rest of the software is only available in C or in IBM-PC executable form. However you should not need to understand or modify any of this C-only software -- you will just need to compile it once on your system. If you don't have a C compiler please contact the organizers; we will attempt to supply you with a binary executable for your machine. 2.3 Obtaining the Software and Documentation -------------------------------------------- There are three basic ways to obtain the double auction software: 1. Copy it electronically from the public directories of the sfi.santafe.edu computer at Santa Fe, using 'ftp'. 2. Request floppy disks from Santa Fe. This is most appropriate if you intend to run the software on an IBM-PC or compatible. 3. Request that the software (and optionally the documentation) be sent to you by electronic mail from Santa Fe. The documentation is all available in electronic form (as simple ascii files), and can be included with any of the above methods. Alternatively you can request printed documentation from Santa Fe. These methods are described in more detail in the following subsections. OBTAINING THE SOFTWARE AND DOCUMENTATION WITH FTP To obtain files from Santa Fe via ftp, follow the following steps: 1. Connect to sfi.santafe.edu with ftp. On most computers the command "ftp sfi.santafe.edu" will do this. 2. Specify the user name "anonymous". 3. Specify your own last name (up to 8 characters) as the password. You should then get ftp's prompt (usually "ftp> "). 4. cd pub 5. cd dat 6. If you plan to get the .tar.Z files or dos files (see below): binary 7. Use a combination of the following commands to get the files you need: a. cd to change to on the remote machine. b. get to copy to your machine. c. mget to copy all files matching to your machine. E.g. *.c matches all .c files. d. prompt to turn off prompting for each file; use before mget if you want all matches. e. ls to list the files in the current directory. f. lcd to change your local directory. 8. quit The organization of the directories and files in the pub/dat directory is as follows (names with lines descending beneath them are directories): pub/dat | |--- README (contains this chart and Notes) |--- directory (list of participants) |--- entries (list of tournament entries) |--- mail (correspondence sent to dat-list mailing list) |--- monitor.tar.Z |--- monitor | | | |--- *.c and *.h source files for monitor | |--- Makefile, dmon.mak, dmon.prj | |--- game, players | |--- README | |--- players | | | |------ C.tar.Z | |------ C | | | | | |--- *.c and *.h files for C players and human player | | |--- Makefile, *.com, *.mak, *.prj | | |--- helpfile (for human player) | | |--- README | | | |--- fortran.tar.Z | |--- fortran | | | | | |--- *.F and *.h files for Fortran players (needs pp) | | |--- Makefile, Makefile.cray, make.com | | |--- README | | | |---- pascal | | | |--- skeleton.pas for Turbo Pascal | |--- skeleton.p for Unix Pascal (pc) | |--- skeleton.vms for Vax/VMS Pascal | |--- skeleton.generic for any Pascal (needs pp) | |--- Makefile | |--- README | |---- misc | | | |---- dani.tar.Z | |---- dani | | | | | |--- dani.c, inet.c (source files for dani) | | |--- Makefile, make.com | | |--- README | | | |----- pp.tar.Z | |----- pp | | | |--- *.c, *.h source files for pp | |--- Makefile, make.com | |--- README | |----- doc.tar.Z |----- doc | | | |---- individual chapters of the documentation | |----- dos | |---- dmon.exe |---- gdmon.exe |---- human.exe |---- player.exe |---- pp.exe |---- *.bgi and *.chr files for gdmon (PC graphics) Notes on the above: 1. The .tar.Z files are compressed files that contain the whole directory listed immediately below them. These are only useful if you have a Unix system with 'uncompress' and 'tar'. If you have these you can do the following: a. Get the .tar.Z files you need USING THE BINARY MODE of ftp. b. Uncompress each file (e.g. "uncompress monitor.tar.Z"). c. Unpack each file with tar (e.g. "tar xvpf monitor.tar"). This will make the directory concerned (e.g. monitor) within your current directory, and fill it with the files. d. Delete the .tar file. 2. Most directories contain a README file. Read this before attempting to compile. 3. Many directories contain files with scripts for compiling and linking. 'Makefile' is for Unix. A .prj file is for Turbo-C. A .mak file is for Quick-C. A .com file is for Vax/VMS. Read these files before using them; there may be things to customize. 4. The dos directory contains executable binaries and graphics files for an IBM-PC. See the following section for more details on these files. Be sure to use the binary mode of ftp to copy such files. They can then be transferred to a PC in several ways (e.g. PC-NFS). If your interest is just in the PC version, you'll probably find it more convenient to get floppies than to try this. OBTAINING THE SOFTWARE AND DOCUMENTATION ON FLOPPY DISKS If you use an IBM-PC or compatible, it is best to obtain the software on floppy disks. You may alternatively be able to use the ftp method, but will then have to compile everything rather than receiving executables. Ask for floppy disks by writing to: Double Auction Tournament Santa Fe Institute 1120 Canyon Road Santa Fe, NM 87501 Include media/shipping fee of $3 for floppy disks only, or $10 for floppy disks plus complete printed documentation ($7.50 for documentation only). The full documentation is included on the floppy disks (as simple ascii text files) and is also available via ftp. Unless you make a special request, you will receive two floppy disks containing the following: Disk 1: DMON.EXE monitor without graphics GDMON.EXE monitor with graphics *.BGI, *.CHR graphics files used by GDMON.EXE (not needed if you have Turbo-C on your hard disk) HUMAN.EXE interface to a human player HELPFILE file of help information used by HUMAN.EXE PLAYER.EXE sample player program (based on the C skeleton) GAME sample gamefile, specifying game parameters PLAYERS sample playerfile, specifying players in a game PP.EXE simple preprocessor README.PP instructions for PP.EXE PASCAL.DIR directory containing the source for the pascal skeleton player: README information about the Pascal versions SKELETON.PAS Pascal source for the PC Disk 2: C.DIR directory containing the source for the C skeleton players, and the human player: README instructions for compilation etc. SKELETON.C skeleton player HUMAN.C human player CONTROL.C control routines for skeleton & human DEFINE.H header file for skeleton & human *.MAK Quick-C makefiles *.PRJ Turbo-C makefiles TCCONFIG.TC Turbo-C configuration file FORTRAN.DIR directory containing the source for the Fortran skeleton player: README instructions for compilation etc. SKELETON.F skeleton player CONTROL.F control routines for skeleton GLOBAL.H header file SIXCHAR.H file to reduce variables to six characters, if necessary F77L.FIG configuration file for Lahey Fortran DOC.DIR directory containing all the documentation (except that for DANI) in simple ascii text files. Note that this does not include: 1. The source files for the monitor. 2. The source files for PP. 3. The source files and documentation for DANI. 4. Certain files not needed on a PC, but which may be needed or useful if you are merely using PC-floppies to transfer the software to another machine. You should not need any of these for use solely on a PC. If you request it specially, we will send you "Disk 3" containing all the above files, including a README file that explains its contents. Please add $1 for this. All floppy disks will be 5.25 inch, double-sided, double-density, 362K. OBTAINING THE SOFTWARE AND DOCUMENTATION BY ELECTRONIC MAIL This method should only be used if neither of the other two is available. Send your request to: dat@sfi.santafe.edu specifying: 1. Your name and institution. 2. Your e-mail address. 3. The type of machine(s) on which you want to run the Double Auction Tournament software. Specify the operating system (e.g. Unix, VMS) too. 4. The language(s) you want to use for your players (C, Fortran, Pascal). 5. Whether you want the source for the monitor. If you don't get this you can only play with the Santa Fe Token Exchange. 6. Whether you want to be able to play games with the Santa Fe Token Exchange. This is only possible if your site has the appropriate TCP/IP software and hardware capability. We will then send you the files we think you need. No individual file will exceed 50K. Files will be bundled together into .shar files on a Unix system; instructions will be included. Note that binary files cannot be sent via ordinary e-mail. 2.4 Getting Started ------------------- There is a lot of software available, and a lot of documentation. You will not master it all at once. We suggest the following approach: FOR UNIX, VMS, ETC. USERS (MULTIPROCESSING MACHINES) -- SFTE USAGE Before you do anything, try to determine if your machine has Internet TCP/IP access using BSD 4.2 or 4.3 calls. If it doesn't you cannot use the Santa Fe Token Exchange; go to the next subsection. If you can use "telnet" and "ftp" on your machine you probably have the necessary access. To find out for sure, determine whether the following routines are available in your C run-time library: socket() connect() inet_ntoa() htonl() htons() bcopy() bzero() The ones on the first line are the truly essential ones. They may be in a special library. First try to find them via 'help' ('man' on a Unix system). Then, if that fails, ask an expert. Note that for Vax/VMS there are several implementations of TCP/IP; the Double Auction software currently only supports the Wollongong WIN/TCP one. If you have a different TCP/IP implementation and want to use the SFTE, please contact the organizers. If you do have the appropriate TCP/IP access, you can follow the following suggestions to play a trial game with the SFTE. Otherwise, or if the TCP/IP access is dubious or needs work, proceed to the next subsection instead. 1. If you don't have printed documentation, print the appropriate files from the 'doc' directory. To start with you'll want at least "intro", "software", and "players". 2. Get the source files for the C players (even if you ultimately want to use Fortran or Pascal). 3. Read the README file for the C players and follow the directions therein to compile and link the players using INETBASED; compile at least "inquire" and the human player (called "hi" or "human" depending on your system). If you have difficulty just try to compile "inquire". If that doesn't succeed please check that you followed the instructions (e.g. did you customize define.h?) and then contact the organizers (see "Getting Help" below). 4. Try running "inquire". If it succeeds in connecting to the SFTE, you should get a message telling you about the schedule of games at Santa Fe, or a message that says a game is about to begin. If instead it says (possibly after up to a minute or so of trying) that it couldn't connect to sfi.santafe.edu, the problem may either be with the network or with your machine's access to it. Try again later, and keep on trying for a day or more before concluding that there's a real problem. If you have the "ping" command, try "ping sfi.santafe.edu" -- if this responds with "sfi.santafe.edu is alive" then inquire should work too. Asking a network expert may also help. 5. If "inquire" works, try running the human player. Unless you use it at the right time (just before any hour), it should give the same message as inquire. Using it just before the hour should allow you to play a game with the SFTE. Study the "intro" and (at least briefly) "players" chapters of the documentation before attempting to play, but don't be afraid to experiment. Use the "quit" command when you tire of playing. As long as you completed at least the first period, you should receive a listing of the whole game by electronic mail after it is over. Study this in conjunction with the "monitor" chapter of the documentation. Please tell the organizers if you don't receive a game listing by electronic mail within a few hours of playing a game. 6. You can also try compiling and running a skeleton player (called "di" or "skeleton" depending on your system). This is actually simpler than the human player. When you run it at the right time it should play a game with the SFTE, displaying it as it goes. 7. You now have three directions in which to proceed: a. If you want to write in C, and only want to use the SFTE (not a local monitor), study the skeleton.c source file in conjunction with the "skeleton" chapter of the documentation. b. If you want to write in Fortran or Pascal, and want to use the SFTE, now is the time to compile and test DANI and the skeleton player in your chosen language. See the appropriate README files and the "dani" chapter of the documentation. c. If you want to set up a local double auction monitor on your machine, follow the suggestions in the next subsection. FOR UNIX, VMS, ETC. USERS (MULTIPROCESSING MACHINES) -- LOCAL MONITOR In some ways this is the most complicated case because you must compile both the monitor and at least one player before you can get anything going. 1. If you don't have printed documentation, print the appropriate files from the 'doc' directory. To start with you'll want at least "intro", "software", "monitor", and "players". 2. Get the source files for the monitor and for the players in the language of your choice. We recommend that you put the player files in a subdirectory of the directory containing the monitor files. If your language is not C, also get the C source for the human player. If your language is Fortran, also get the source files for 'pp' if you don't have a standard Unix system (see the Fortran README file). Make sure you also have any associated README files and makefiles. Also make sure you have 'game' and 'players' for the monitor and 'helpfile' for the human player. 3. Compile the monitor. See the README file for directions. Try running it without any command-line arguments: it should read and list the parameters in the 'game' file, and then stop with a 'no active buyers or sellers' message. If anything else happens, investigate before proceeding; first check that 'game' and 'players' are in the monitor's own directory and contain sensible parameters ('players' should not yet define any players). 4. Compile the skeleton player in the language of your choice. See the appropriate README file for directions. If you choose Fortran you may first need to compile 'pp'. You will have to decide on your communication method, either FILEBASED or PIPEBASED; we recommend PIPEBASED for all Unix and VMS systems. For other systems if you are the first person to try this software, it may be easier to start with FILEBASED. 5. Make a second copy of the compiled skeleton program with a different name (e.g. player2 or player2.exe as appropriate). Simply copying it will work unless you are using FILEBASED communication and the program name has to be built into the program, in which case you'll have to recompile with the new name; see the appropriate README and source files for details. 6. Edit the 'players' file (in the monitor's directory) to specify your two players. See the comments in the 'players' file and in the "monitor" chapter of the documentation. 7. Run the monitor. Now a game between your two players should commence. Note though that games with only one buyer or one seller are not representative of the full game; many strategy issues do not arise. 8. Play with the following to familiarize yourself with the system: a. Adding more players. Note that on many systems you can get away with using the same executable binary player program more than once in a game (simply specify it multiple times in the 'players' file). This will never work for FILEBASED players though; these must always have unique names because the *.in and *.out message files must be unique. b. Changing the game parameters in the 'game' file. c. Controlling the monitor with single letter runtime commands (see the "monitor" chapter of the documentation. d. Sending the monitor listfile output to a file (this gives a different screen display); see the "monitor" chapter of the documentation. 9. Compile the human player. See the directions in the README file from the C source. Note that you need to customize 'define.h' differently for the human player and C skeleton players. Define the human player in the 'players' file, being sure to include the -h flag, as well as one or more skeleton players. Run the monitor, sending the listfile output to a file. You should then find yourself playing a game against the skeleton player(s). 10. To start developing your own strategy, study the "skeleton" chapter of the documentation, and then look at the appropriate skeleton.* source file and the README file in the source directory. FOR PC USERS WITH THE SOFTWARE ON FLOPPY DISKS 1. If you don't have printed documentation, print the appropriate files from the DOC directory on Disk-2. To start with you'll want at least "intro" and "software". 2. Copy the root level files on Disk-1 (i.e. all but PASCAL.DIR) to a suitable directory on your hard disk. Make a subdirectory of that directory for the skeleton programs in the language of your choice (C, FORTRAN, or PASCAL), and copy the contents of the appropriate directory on Disk-1 or Disk-2 into it. 3. As a trial, you can play a simple game, pitting yourself (via the human player interface) against PLAYER.EXE. Get into the directory with DMON.EXE in it, and type: DMON OUTFILE A game should begin with you randomly either a buyer or seller. It will be VERY SLOW, and NOT REPRESENTATIVE of the full game with many players; games with only a single buyer or a single seller (or both) do not raise most of the strategy issues of a full game. But it may help to introduce you to the game and the software. Here are some things to try: a. Type a ? at any prompt. b. Type 'help' at any prompt. Try some of the commands/options listed there, especially u, w, and h. c. Type 'quit' when you are tired of playing. d. After playing, display or print the file OUTFILE, to which the monitor sent its output. For more information about the human player and its commands and display, look in the 'players' chapter of the documentation. For more information about the monitor and its output (as in OUTFILE) look in the 'monitor' chapter of the documentation. 4. To make things reasonably fast on a PC, we highly recommend creating a RAM disk for the players. If you do not currently have a RAM disk running on your machine, one can easily be installed using the VDISK program supplied with later versions of DOS. In your CONFIG.SYS file (found in the root directory) insert the following line: DEVICE=C:\DOS\VDISK.SYS 128 This assumes that your vdisk.sys file is in the C:\DOS directory; modify if necessary. The 128 gives you a 128K RAM disk, which should be sufficient for several players and their message files; increase or decrease as needed. If you have extended memory (beyond 640K) you can install your RAM disk there by adding /E to the end of the above line. Reboot your machine after changing CONFIG.SYS; you should now have a RAM disk as drive D. You can use it just like any other drive except that its contents are lost when you turn your machine off or reboot. Copy your players (.EXE files) to your RAM disk, and change your PLAYERS file to reflect their new location; the directory column should just contain 'D:' (or other appropriate drive letter) unless you make subdirectories on your RAM disk. You can also copy the monitor and its associated files to the RAM disk if you make it large enough, but this will not convey much advantage. Once you have mastered using a RAM disk for your players, the process of copying the appropriate files to it can be automated with batch file. 5. To try a game with more players, make copies of PLAYER.EXE with different names (e.g. PLAYER1.EXE etc.), and modify the PLAYERS file appropriately to define the players in each game. You can try games with or without a human player. If you include a human player you must direct the monitor's output to a file (e.g. 'DMON OUTFILE'); without a human player you can let the output go to the screen (e.g. 'DMON'). If you don't have a human player the monitor will respond to several single-letter commands from the terminal; see the "monitor" chapter of the documentation. 6. To try a game with graphical display of the supply and demand curves and transaction prices, use GDMON instead of DMON. See also the discussion of the -g and -p options in the "monitor" chapter of the documentation. 7. You can also try changing the game parameters in the file GAME. 8. To start developing your own strategy, study the "skeleton" chapter of the documentation, and then look at the appropriate SKELETON.* source file and the README file in the source directory. You should try compiling the skeleton without any changes (besides the customization required -- see the README) before developing any new strategies. The resulting player program should behave essentially like the PLAYER.EXE provided. 9. There is a considerable advantage to having a small executable player file, since it must be loaded frequently. You may want to explore ways provided by your compiler to minimize the .EXE size, including inhibiting some forms of debugging. Some hints are provided in the README files and makefiles. In general we find that Fortran executables are larger than C executables, which are larger than Pascal executables. 2.5 Getting Help ---------------- We will try to assist you in getting our software to run on your system if necessary. We request, however, that you make an effort to thoroughly understand this documentation before requesting individual help from us, since many standard questions are already answered in the documentation. Additional questions have also already been answered by the organizers in the "mail" file available by FTP from pub/dat (see section 1.5 and section 2.3 for details). The organizers are available to answer questions on the operations of the monitor (pipe-based and file-based only), the skeleton players in C, Fortran, or Pascal, DANI, and PP. You can contact us by mail, phone, fax, or e-mail. E-mail is recommended, particularly because the expert you need may not be physically at Santa Fe, but will receive your message elsewhere. In all cases, please make it clear that you are referring to the Double Auction Tournament. Please realize that the organizers have full-time positions elsewhere, and so one shouldn't expect our technical help to have as rapid a turn-around time as for commercial software. Address: Double Auction Tournament Santa Fe Institute 1120 Canyon Road Santa Fe, NM 87501 Phone: (505) 984-8800 (office hours 8:30 am-5:00 pm MST) Fax: (505) 982-0565 (24 hours) E-mail: dat@sfi.santafe.edu (for all general inquiries. Do NOT send initial inquiries to "dat-list" since this is a mailing list that goes out to hundreds of people. Send mail to "dat-list" only after reading section 1.5) palmer@sfi.santafe.edu (for C, Fortran, monitor, DANI, PP) miller@sfi.santafe.edu (for Pascal) jpr@sfi.santafe.edu (for questions on DA rules, strategy, etc)