★ APPLICATIONS ★ CP/M ★ CONDOR 1 ★ |
| Condor 1 (Amstrad Action) | Applications Cp/m |
data into it. To get onto the data entry screen you use the ENTER < dataset name> command from the 'A»' prompt. The record card appears on the screen, and you simply type your data into the relevant fields. Of course 'simply' here is only relative -you've still got those miserable editing keys to contend with. Up to this point, as you may have gathered, Condor is fairly unfriendly. Putting it at its worst the program is cumbersome to set up, it's command-line- rather than menu-driven, it fails to use the full PCW screen and its editing controls are completely arbitrary. Anyone dismissing the package now, however, would miss out on an awful lot. When it comes to using the data you've typed in, Condor's pretty impressive. Suppose you want to see a list of customers on a subscription .list dataset called SUBS, for example.From the 'A>>' prompt just type in LIST SUBS BY SURNAME INITIALS START.DATE FINISH.DATE" where SURNAME etc are the names of the fields you want on the list. Up comes the list in neat columns, one for each field, complete with column headings. For a hard copy equivalent of this, there's a PRINT command which works in exactly the same way. Nothing too impressive in that, you might think; nice, natural syntax certainly, but hardly an earth-shattering command. The natural command syntax carries over into other commands, however. Typing in SORT SUBS BY SURNAME INITIALS ST ART.DATE FINISH.DATE takes a little thinking time on the computer's part, but works fine. If you LIST the SUBS dataset again, you'll see that it's now been sorted into alphabetical/numeric/date order by each of these fields, in order of precedence. In other words, 'Jones'comes before 'Smith', 'J A.Jones'before 'J.B.Jones'and so on right down to the order of the finishing dates on two otherwise identical entries. If you'd told it to, Condor could have sorted by a further 28 fields. If you think about it, you'll now see one of the reasons behind the use of a command line to enter instructions. A menu might be quicker on single instructions, but it would lose out by some way on a command like SORT - and we haven't got onto the complex commands yet. SEARCH COMMANDS If you want to alter a given record, you can easily do so with the UPDATE command. Suppose you discover, after typing in a large number of addresses, that Bristol is in Avon rather than Somerset. Type UPDATE SUBS WHERE CITY IS BRISTOL, and the program offers you all the records with Bristol addresses. You can leat through them, modify them to your taste or print them all out. If you want to do rather more with your chosen records than UPDATE allows you to, you can use the SELECT command. Continuing the previous example, you can type SELECT SUBS WHERE CITY IS BRISTOL. This creates a temporary dataset called RESULT, which consists of all records with Bristol addresses. You can LIST, PRINT or UPDATE this RESULT dataset - and generally treat it like any other dataset - but this is not necessarily a good idea. You see, RESULT is only temporary. Its current contents will be lost the next time you use SELECT or certain other commands. This isn't always undesirable. You can, for instance, use SELECT RESULT WHERE... to narrow the selection down still further. If you're going to want the RESULT contents in the long term, however, it's best to put them somewhere safe. To do this, you use the SAVE command. SAVE BRISTOL, fox example, would put the contents of RESULT into a new dataset called BRISTOL. GETTING MORE ADVANCED So far the commands have all been very natural and logical, but then they've not been doing anything very complex. From now on, things get rather more complex. This is the direct result of Condor's power and flexibility. The fact it makes sense at all is a tribute to the manual, and the natural syntax of the system itself. There are other advantages to this system than just safety. For one thing, the satellite datasets can be speciiised, cut-down versions of the full-size master. A payments dataset, for instance, need only carry the amount paid and enough other fields to identify the customer concerned. The other customer details on the master dataset card - even the money owed by the customer prior to the payment are irrelevant for these purposes. Powerful, flexible commands can transfer the data across and compute new figures for the amounts now owed etc. This cut-down card technique makes it immediately clear exactly what you're supposed to do. If you're presented with the master card and all the customer's details on it, you'll have a job finding the right field let alone working out what form the data's meant to take. The payments card, however, will be much less cluttered and can carry explanatory notes. AUTOMATION A division is starting to emerge in the use of Condor. On the one hand, you have the more experienced user who sets up the different datasets and their respective cards; and on the other, you have the operator who simply fills out the relevant cards as part of the office procedure. The problem comes at the end of the day, when the relevant transfer and computation commands need to be entered. The transfer commands are not easy things fa use. The choice of command words and the syntax they use are very; helpful, but the underlying concepts are not always easy to grasp or explain. While I could give examples, I don't have anything like the space I'd need to explain them. The manual is essential here, and it is an enormous piece of work. Since only the more interested user is going to wade through al of it, there has to be some way of simplifying the transferral task tor casual operators. There is such a way, and it is called the command procedure file. This is a set of instructions for Condor to follow. It can contam conditions, use variables, display messages and take input from the keyboard - it is, in other words, a program. Any series of instructions you could type in at the 'A»' prompt can be built into a command procedure. Thus, a complex sequence that transfers payments in and recalculates money owed can become RUN PAYMENTS - as far as the operator's concerned, at any rate. Of course, someone's got to write the command procedure. This isn't actually a very difficult task. It's a lot like producing a simple BASIC programme, and you only have to write the thing once. You can carry the automation even further, if you like. By using the FORMAT command, you can create help menus. In use, the relevant menu option is selected by entering the option's number; there is no need to use the command line in the conventional way. Menu options can lead to command procedures or to other menus - it's up to you. In this way you can create a whole menu-driven system which completely insulates the operator from Condor's complexities. DOCUMENTATION The review documentation was pre-production, but even with important diagrams missing it explained most features extremely clearly. It is not. however, light reading. The finished version is, I'm assured, even larger - so get your bookshelf strengthened now. CONCLUSION The above account necessarily omits several features. There's Condor's ability to swap files with word processors for one thing, and it's report-generating capabilities for another. What it has demonstrated, I hope, is this: Condor 1 is an extremely powerful package which goes far beyond what an average PCW database can do for you, but it's going to take some effort for you to get the most out of it. Even with the cut-price edition of dBase II on it's way, Condor 1 is easily the cheapest way of getting this kind of power. If you've got the size of data-handling job that needs heavy-duty software, it's excellent value for money.
|
