The Happy Promise of an Unconditional Guarantee One reviewer claimed a 30% savings in multiple-user development with the dMILL All-Networks Productivity Kit for Clipper, but you may save 300% to 1,000% or more depending on your situation. Experienced multiple-user programmers have reported learning many new topics and techniques. Greg Lief's Aquarium said the Kit is: * INDISPENSABLE * an excellent value * for all skill levels * works like a champ * A REMARKABLE ACHIEVEMENT BY A REMARKABLE PERSON! The Kit is unlike any other product. Its services are unique and its quality is "REMARKABLE." If you don't find the Kit to be INDISPENSABLE, just return it within ONE YEAR -- 365 DAYS -- for a full refund: YOU MUST BE HAPPY OR YOUR MONEY BACK! We can offer an unconditional guarantee with complete confidence -- and you can have complete confidence in us -- because no one has EVER returned a Kit for a refund. Period. Decision Support The demo menu gives you access to several text files on the demo diskette which support the decision-making process of you and your managers as you determine whether to license the Kit and incorporate its infrastructure support into your operations. In addition to "Questions and Answers", you will find two quizzes and several lists. The "Programmer's Quiz" helps you evaluate the level of sophistication in your handling of resource contention and process synchronization in your current multiple-user applications. If that level is already publication-quality and fully supported by a comprehensive set of helper utilities, the Kit's source code libraries have nothing to offer you. The "Manager's and Programmer's Quiz" helps you and your managers evaluate the costs and benefits of using the Kit. The cost of a Kit license is of smaller concern than the fact that (A) you must incorporate the Kit's infrastructure support into your development environment, (B) your multiple-user applications will have the functionality provided by the Kit, and (C) in the case of resource contention handling, your multiple-user applications will have the look and feel provided by the Kit. The following menu items will help you understand the scope of the Kit and its specific benefits: * Under the heading "Pictorial," you can find a diagram which depicts the components of the Kit and one which shows how the Kit relates to Clipper and other third-party products. * Under the heading "Specs," you can find the Kit specifications, including control settings and function lists for the Summer '87, Clipper 5.01, and 5.2 source code libraries. * Under the heading "Course," you can find the titles, topics, and skills taught in the lessons that make up the dMILL Network Course for Clipper. (The author also teaches this material in his MURAD seminar.) * Under the heading "Magazine," you can find the text of the rave review from Greg Lief's Aquarium journal for Clipper. After you have worked through the information files, you are ready to run the demonstration programs. You'll read how to run these programs later in this file, but before you will be able to understand the significance of information which the demos present, you must understand some of the basic problems which confront multiple-user developers. The Problems First, let's look at the problems that managers, programmers, and end-users have with developing or using applications which share resources among several people simultaneously on the network. We will see that the dMILL All-Networks Productivity Kit for Clipper provides an infrastructure to support the development of publication-quality multiple-user applications with minimum time and cost! Managers A manager of course wants multiple-user applications which are developed in a reasonably short amount of time, which do not crash the network or any workstations, and which allow people to share resources as smoothly as possible. Unfortunately, multiple-user programming is far more complex than single-user programming, so programmers often take vast amounts of time to develop applications for the network. Furthermore, these applications are often unstable -- they fail unpredictably -- and they may cause users to needlessly interfere with each other's work. End-Users People who use networked applications that share resources often experience a large number of problems. In the "deadlock" situation, sometimes called "deadly embrace," users wait and wait for resources that never become available; the only solution is to re-boot one or more workstations, which often damages files -- the sad truth is that it may take WEEKS to repair damaged files. Users frequently find that they spend a lot of time waiting for files and records which are being used by others to become available, which is often avoidable if the programmer is sufficiently knowledgeable. And, of course, users often wait months or years for single-user applications to be converted to share resources on the network. This kind of delay can definitely be avoided by knowledgeable programmers who have the right tools: a properly equipped programmer should be able to able to convert 1 to 4 megabytes of debugged single-user code to its multiple-user form in a month. Programmers Programmers have a great many problems in converting single-user applications to share resources on the network, or in developing multiple-user applications from scratch. Almost all of these problems are caused (1) by a lack of understanding of the many issues which affect multiple-user programming or (2) by not having the proper development tools. The result is applications which fail unpredictably in both subtle and dramatic ways, applications which make resource-sharing very difficult and time-consuming for the users, and applications which take a long time to develop. The Solutions Several vendors currently offer products to assist dBASE dialect programmers in developing network-ready applications in ways which please both managers and users. T. David "dMILL" Millican, the creator of this demo, is the author of a line of docusoftware(TM) products in which documentation and software is given equal weight in design and implementation. These products are crafted under the philosophy that elegant and powerful tools lead to high programmer productivity only when the tools are used in an enlightened and informed fashion. Thus, docusoftware for the dBASE dialect programmer offers elegant tools with extensive tutorials to show practitioners how to approach the theoretical limits of productivity! In the network area, docusoftware products include: * dMILL All-Networks Productivity Kit for Clipper * dMILL All-Networks Library for Clipper 5.01 (Professional Option) * dMILL All-Networks Library for Clipper 5.2 (Professional Option) * dMILL All-Networks Library for Summer '87 Clipper * dMILL Network Course for Clipper * dMILL All-Networks Productivity Kit for Generic xBASE (announced only) The Professional Options of the dMILL All-Networks Productivity Kit for Clipper (also known as the "dMILL All-Networks Library for Clipper 5.01" and the "dMILL All-Networks Library for Clipper 5.2") gives Clipper 5 users an encapsulated implementation of the source code library. The "dMILL All- Networks Library for Clipper 5.2" fully supports RDDs and all of the multiple-user features of Clipper 5.2. The dMILL All-Networks Library for Summer '87 Clipper and the dMILL Network Course for Clipper are components of the Kit, although the Course may be purchased separately. Buzzwords International of Cape Girardeau, Missouri offers the dANALYST programmer-productivity product for the leading dBASE dialects and the C programming language, which is compatible with the dMILL Network Kits. There are two parts of the conversion of a single-user application to its multiple- user form: (1) the modification of algorithms which work in single-user mode but which require alteration to work successfully on the network and (2) the conversion of seven standard code patterns from their single-user form to their multiple-user form, wherein calls are made to routines which handle resource contention. dANALYST can perform the second kind of work automatically -- the converted code will call routines in the dMILL Network Kits in the appropriate places. For example, you can use dANALYST for Clipper and dMILL Network Kit for Clipper to convert a single-user Clipper application to share resources on the network in a fraction of the time it would take you without one or both products. Communications Horizons of New York City offers NetLib, a library of network functions for advanced Clipper programmers. There is virtually no overlap in the functionality provided by NetLib and the software component of the dMILL All-Networks Productivity Kit for Clipper. NetLib and its clones can be used to extend and enhance certain functions of the dMILL All-Networks Productivity Kit for Clipper, and to provide functionality which is not available from the Kit. The dMILL All-Networks Productivity Kit source code libraries are written entirely in Clipper and are 100% overlayable. These libraries are compatible with Blinker from BlinkInc. of Richmond, Virginia. Professional Handling of Resource Contention The central problem of multiple-user programming is the handling of resource contention: the situation where two or more users compete for the same resource. If you try to use a single-user application as if it were coded for resource-sharing, then when you experience resource contention, you will typically receive an uninformative system error message such as "file unavailable," followed by an invitation to quit, retry the offending command, or ignore the error condition. In some cases, the "retry" option may eventually succeed, but the "ignore" option leads to trouble and the "quit" option is usually the only safe response. Notification Therefore, the first requirement of professional-level handling of resource contention is notification: tell the user what has happened. It is always possible to tell the user which requested file or which requested record is unavailable, as in the messages "Accounts database in use" and "Record 57 of the Employee database is in use." Unfortunately, it is not always possible to have the message say who is holding the unavailable resource, because MS-DOS networks have no standard way of identifying workstations! Under some conditions, you can use special software to programmatically discover the user of a requested, unavailable resource. NetLib can perform this service for Clipper applications, and dBASE IV can identify record lockers for databases on which the CONVERT TO command has been run. Version 5 of the dMILL All-Networks Productivity Kit for Clipper and the dMILL All-Networks Productivity Kit for Generic xBASE will be able to identify record lockers for Clipper, FoxPro, and dBASE IV applications. Automatic versus Manual Retry In the example above, the system gave a "retry" option when resource contention was detected. If you need a file that Nancy is using, but she is almost done with the file, then you can successfully proceed after retrying the command enough times; this is "manual retry." The simplest multiple-user applications offer manual retry as part of their notification, as in "The file you want is not ready. Press R to try again." A professional-level application offers automatic retry. For example, the default resource-contention message for a Clipper application prepared with dMILL All-Networks Productivity Kit that requests Accounts.DBF when it is unavailable is "Waiting for ACCOUNTS.DBF. Press SPACE BAR to stop waiting." Behind the scenes, the application asks repeatedly for Accounts.DBF until it is available or the user presses the space bar. The application could ask for the resource as often as possible, but this might needlessly load the network. Retry Delay During automatic retry, an application could execute a loop of the form DO WHILE () ENDDO but this request might be issued several hundred times a second; that slows down the network and brings no benefit to the user. If the file I ask for becomes available after 10 seconds or after 9.88 seconds, it is all the same to me. Therefore, professional-level applications impose a delay factor, as follows: DO WHILE () ENDDO The dMILL All-Networks Productivity Kits offer the programmer several settings to control the behavior of its contention-handling routines. One such setting, called "NetDelay", specifies the amount of time to wait between resource requests. Deadlock ÄÄ The Deadly Embrace Let's say that you and I are running two different network programs which both require exclusive use of Employee.DBF and Tax.DBF. You and I start at the same time, I request and receive exclusive use of Employee.DBF and you request and receive exclusive use of Tax.DBF. Then I request exclusive use of Tax.DBF and you request exclusive use of Employee.DBF. You can see that we are both waiting on each other ÄÄ this is deadlock ÄÄ and that the only resolution is for one of us to quit. If I quit by rebooting my workstation, then I may damage Employee.DBF, but a properly programmed application gives other alternatives which preserve file integrity. Manual versus Automatic Timeout Earlier we contrasted manual and automatic retry, and now we contrast manual versus automatic timeout. If my program has been implemented with a dMILL All-Networks Productivity Kit, then when I ask for the unavailable Tax database, my screen shows a message like "Waiting for TAX.DBF. Press SPACE BAR to stop waiting." If I press the space bar, I have manually signaled the program to stop waiting, which is manual timeout. My program will then quit or take some other programmer-specified action which includes closing Employee.DBF; at that point, your program can get exclusive access to Employee.DBF and proceed. But what if neither of us presses the space bar to stop waiting? In that case, we still have deadlock, so an additional mechanism is needed, which is called "automatic timeout." One of the settings that controls dMILL All-Networks Productivity Kit routines is called "TimeOut". This setting specifies the maximum amount of time to wait for a requested resource to become available. If this setting is set to five minutes (call DmSet("TimeOut", 300)), then you and I cannot block each other for more than five minutes at a time; deadlock is avoided in all cases through manual timeout or automatic timeout. The Software Engineering of Resource Contention Handling When we analyze the problem of resource contention from the viewpoint of software engineering and docusoftware, we see that a fully-professional programmer aid must provide the following services: * notification * automatic retry * retry delay * manual timeout * automatic timeout * tracing and debugging facilities * flexible installation options We have already looked at the first four services, which are all the services required in a debugged and installed application. However, all programmers know that a software tool must be installed, and applications must be debugged before they can be released to users. The dMILL All-Networks Productivity Kits offer a number of installation options, depending on the dBASE dialect which the Kit supports. For example, all Kits offer the "HandCode" setting to control the action taken by an application in the event of automatic or manual timeout. When DmSet("HandCode") is false, the application returns to its main menu with no special coding required by the programmer (except for the use of a special batch file); otherwise the application executes the code that the programmer writes to handle specific resource contention situations. (The usual action of such special code is to return the user to the previous menu, rather than the main menu.) All Kits offer these settings to support the development and debugging of networked applications: * DmSet("TraceResourceRequests", .T.) is called to show all resource requests. * If DmSet("TraceResourceRequests") is true and DmSet("TraceAnimate") is false, the resource requests for available resources will only appear briefly. * If DmSet("TraceResourceRequests") is true and DmSet("TraceAnimate") is true, the resource requests for available resources will stay onscreen until you press the space bar or until DmSet("TraceSpeed") seconds have elapsed. * When you call DmSet("TraceUseParsing", .T.), the database, index, and exclusive clauses of USE commands are shown onscreen. Sample Code Here are some samples of code which show you how easy it is to gain the benefits of the dMILL All-Networks Productivity Kit in your applications. First of all, you get the convenience of letting the Kit handle denied resource requests if you don't want to code the exception handling yourself. Consider the following USE statement as you might code it in a single-user application: USE Accounts INDEX Month,Year ALIAS Ledger NEW EXCLUSIVE If you have the Kit handle denied resource requests, the multiple user equivalent would be as follows: DmSet("HandCode", .F.) && This is the default. lDmUse("Accounts INDEX Month,Year ALIAS Ledger NEW EXCLUSIVE") If the resource is denied the application quits to DOS with an ERRORLEVEL of 255 so that an application-launching batch file can restart the application following manual or automatic timeout. If you handle the exception yourself, then you code as follows: DmSet("HandCode", .T.) && You hand-code the exception handling. IF lDmUse("Accounts INDEX Month,Year ALIAS Ledger NEW EXCLUSIVE") ELSE ENDIF If you want to hand-code all exception handling, include the statement DmSet("HandCode", .T.) once at the beginning of your program. If you never want to hand-code exception handling, no DmSet("HandCode", .F.) call need be made as this is the default. If you want to hand-code exceptions on a case-by-case basis, you would call DmSet("HandCode",) as necessary. WHAT COULD BE EASIER? Running the Demonstration Programs You now have the background to understand the sample file and record locking in this demonstration. First, choose "Demos" and then "Network Simulation" to view a simulated network session. Your screen will show a simulation of results at two workstations as two simulated users experience resource contention. Then, if you prefer, choose "Concurrent Demo" to execute sample code which uses the dMILL All-Networks Productivity Kit routines to handle resource contention between one (or more) simultaneous network users. An initial set of data-entry screens prompts you to specify values for all Kit settings, such as tracing, tracing message persistence, reporting of USE clause parsing, delay between resource requests, and delay preceding automatic timeout. A menu offers you options to use the test file in exclusive or shared mode, and to lock and edit or share and display a record. You may invoke the Summer '87 Clipper debugger by typing ALT-D. This facility will permit you to examine the locking activity of the demonstration on its one test database with its single test record. Select "Display" on the top menu and then select "Database" on the pull-down menu. (NOTE: The demonstration program is implemented in Summer '87 Clipper because there is no way to detect record or file locks in Clipper 5.01 and no way to detect file locks in Clipper 5.2.) Background Information and Sales Orders Choose "Basics" and then "Company information" on the demo menu for background information on the Kit publisher, Database Software Consultants. Choose "Basics" and then "Order form" for order information. Database Software Consultants works hard to support you with "World Class Tools for World Class Programmers." Our promise to you is that you MUST be delighted -- OR YOUR MONEY BACK."