Data Management to the Rescue?

Kathy Lang checks out a flexible new CP/M package.

Regular readers will know that many of the packages I’ve reviewed in this series have particular areas of strength that make them well suited to certain areas of data management. This month’s offering, a British package called Rescue, which comes from Microcomputer Business Systems and runs under CP/M, is a general-purpose, menu driven data management package which has much in common with others in this field. But it has unusually flexible provision for different types of information, and its data validation is among the best I’ve seen.

Rescue comes in three parts: the first deals with configuring the system for your computer, and is not needed again unless you make major changes. The second part covers the creation and amendment of the data files, and of the screen and report formats, while the third permits record amendment and display. This separation makes it easy to set up a system in which most users have access to the information in the files, but cannot change the format of those files or interfere with any provision for protecting parts of the data for security reasons.

Data is stored in fixed-length records in Rescue, but some ingenious methods are used to keep data storage to a minimum – I’ll say more about that later. Once you’ve set up a record format, you can still add fields to the end of the records, but you can’t change the sizes of existing fields unless you’ve made provision for that in advance. (MBS is apparently about to release an option to permit more radical changes to existing files, but it isn’t available yet). You can access the records in two ways. Individual fields may be used as keys, and any one of them used to access a particular record for display and/or editing. You can also select subsets of the data by setting up a set of selection rules, which are used to extract a set of records for browsing on the screen or for printing. You can set up as many screen and report definitions as you please for any set of data; these definitions need describe only a few fields in a record if necessary, and any or all of these descriptions may be password protected.

Rescue is used through menus, but users can set up their own menus through quite simple procedures. Thus you can set up a series of operations to be activated by one menu option. You can’t at present access one file from another, so that the current version of Rescue does not have true database capabilities.


Figure 1 shows the major constraints imposed by Rescue. The maximum record size of 1024 is the same as several others I’ve reviewed, but Rescue’s dictionary capability makes it more economical of data storage than many.

Some people will find the limitation of 60 characters in a field more serious. I haven’t included in the figure a full list of the field types allowed, as it is very lengthy. Virtually any kind of data format can be expressed with one of the field types provided. I’ll say more about them in the next section.

File creation

The process of file creation is shown in Figure 2, which is a ‘road map’ of all the menus associated with the data definition part of Rescue.

The first stage in file creation involves setting up a data description file, specifying the basic format of each record and the keys it will have. At this stage you must assign a data type to each field. There are four main groups of data alphanumeric, numeric, date, and dictionary. There are several forms of data type in each group; for instance, character data may be just that and contain any valid ASCII character, or they may be alphanumeric, in which case they may only contain letters or digits and any attempt to enter invalid data will be rejected by the system. There is quite a variety of numeric fields, too, including money (sterling). You can specify that a field is to conform to a mask, to ensure that such items as account references, which often have prescribed formats, are entered in a valid form.

Probably the most unusual type of data is the dictionary field, which permits the person entering data to include only certain values. There are two kinds of dictionary field; a short form, which permits up to 29 characters in total to be used for each field, and a long form, which allows up to 255 entries, each of up to 60 characters. The latter are shared among all the fields in the file, so supposing one has a series of questions each with the same range of answers – for example, answers ranging from Poor to Excellent in a market research survey – you only need one dictionary entry for all the fields to refer to. Each response takes up only one character in the record in the data file for either type of dictionary, so the method is really a way of combining coding with captions for codes.

Every field within the record must also fall into one of four entry categories: mandatory (ie, the field must always have a value), optional (the field may be empty), calculated or display-only. Calculated fields are derived from calculations on constants or on other fields in the same record. Display-only fields are provided so that for certain modes of access fields can be shown but not altered – account numbers might for instance be protected in this way. Any field in a record may also be linked to others in a number of ways.

Direct linkage provides for situations where some fields only have values if another field – said to be the controlling field – has a certain value. For instance, details about a property might say if the property were freehold or leasehold but only if it were leasehold would it be sensible to ask for the life of the lease and the annual charge. This approach can also be used to deal with records with lists of information; you might want to store the names of all a person’s children where some people might have as many as six, without asking six questions about childless people. Most packages expect you at least to hit one key for each question when entering data from the keyboard but with the Rescue approach entry can be more finely tuned to stop
prompting for answers if they are not needed.

During file definition you must also specify the fields which are to be used as keys. Rescue treats the key field which is physically nearest to the beginning of the record as the main key, in that you have to ask specifically for other keys when you come to access the file; so it can save a little time to think about what order to store fields in the record. Up to 10 fields may be defined as key fields. Keys may be either unique or duplicate, and Rescue checks when supposedly unique key values are entered. All the key fields are referenced from a single index, which is automatically kept up to date when data is added or amended.

The next step is to define screen and print formats for the records; you can have as many of these as you wish, and each may describe only parts of the record – for instance, to prevent confidential information being seen by everyone. Next, you tell Rescue to set up an empty data file and structure the index file, and finally you construct any custom-defined menus you will need If you do specify more than one screen or report definition, then you will have to do some customisation of the menus in order to use the alternative formats, but this is quite a straightforward process.

Input and editing

The provisions for data validation given by the dictionary facilities, by the variety of data types and by the range checking which can also be set up at file definition time, are extremely powerful – it’s always possible to get the data wrong in a logical sense, but Rescue makes it quite hard to get it wrong in any other sense. That said I did find the mechanics of correcting data a bit clumsy; if you’ve made a mistake and go back to edit a record you can say where in the record you want the editing to begin but from there you must work sequentially through – you can’t work back up the screen either when entering or editing data. Since the program requires you to have a terminal which can move the cursor left and right, it seems a bit strange not to utilise cursor movement up as well, since no terminal is likely to have horizontal movement but not vertical…

When you retrieve records for amendment, you do so by specifying a particular key value; you can specify the use of any key, but you have to get the value of the first four or five characters exactly right (except that Rescue is ‘case-blind’ in this situation, so it will for instance match Smith and smith). Even when matching exactly on a key value you may retrieve more than one record, as duplicate keys are allowed. But searching for field values within ranges is only possible when you want to look at records, not when you want to change them.

Screen display

I said that you can have several definitions for a single file, so that records can be displayed on the screen in different ways for different users or applications. These screen definitions can be created by copying existing definitions and amending them, but I couldn’t find a way to see what definitions I already had except by going out to CP/M and using the Directory command. Screen layout is specified by giving row and column coordinates for each field you want to display, which I found much more difficult to use than the ‘paint-a-screen’ approach which has become fairly common. The coordinate approach also makes it more difficult to amend the layout, though Rescue does have one provision to make this a little easier by letting you specify a re-ordering of the display without changing the absolute coordinates.

The screen layouts are set up in the ‘definition’ part of Rescue. However, they are invoked from the main part of Rescue, through executing one of the options in the menus shown in Figure 3. Display can be of records specified either by matching one key, or by selection using the selection and extraction procedure which is described later.


Rescue uses the same mechanism for printed reports as for screen display, so both are strictly record based. The only provision for aggregated information is totalling of numeric fields. It is possible to force page-breaks when values of particular fields change, but subtotalling is not provided. There is, however, a very flexible facility to interface with Wordstar and Mail/Merge, so it is easy to use them in combination with Rescue to write circular letters and concoct sets of standard paragraphs.


Rescue provides the ability to select parts of the data file for browsing, printing or further selection. The main method of doing this is to set up a set of selection rules in a file, and then to apply these to the data file to produce another file containing the selected records. The selection rules are very flexible: you have all the usual comparison operators (less than/greater than/equal to/not equal to) and data values can be compared with constants or with the values of other fields in the same record. Rules can be combined to provide ANDing and ORing within and between fields, and these combination facilities together with the NOT operator make it possible to select virtually any combination of values you could need. However, personally I don’t like the need to set up rules in a file, as it is rather cumbersome in practice; if you are using the standard facilities menus you must go to the ‘Maintain Rules’ menu (at the third level of menus), create the rules, then go back to the first level of menus and down to the third level ‘Extract and Sort’ menu to actually extract the records you need. Finally (from the same Extract menu) you can display or print the records that have been found. This provides a sharp contrast to the command language approach, in which one command will extract your records and a second at the same level will display them. However, you could tune the menus in Rescue to avoid some of this ponderousness, so it’s better in that sense than menu systems which you can’t adapt.

While actually comparing fields, upper and lower case letters are regarded as equivalent. You can use wild codes: ? will match any one character, * will match one or more characters. For dictionary fields, the order for comparison purposes is the order in the dictionary, so if you have a set of answers with Poor as the first and Excellent as the last Poor will be regarded as ‘less than’ Excellent even though P comes after E in the alphabet. This is usually what you want and with much coded data would be a very valuable feature.


Rescue can sort a data file on up to five fields in one operation; the process is similar to selection and you can also combine selection and sorting to give a sorted extract file. Sorting is either in ascending or descending order, as with selection dictionary fields sort in their dictionary order (Poor before Excellent) rather than in alphabetical or numeric order. In addition ordinary character fields can be given a sort value which is different from their simple alphabetical order. This could be particularly useful where you had fields such as book titles which often have prefix words such as A or The, which you want to ignore for sorting purposes but wish to include as part of the field for printing (In most packages these prefix words must occupy a separate field, which will be empty for titles without a prefix word.)


The calculation facilities in Rescue are quite powerful in the input phase, and practically non-existent after that. When you set up a data definition file, you can specify that a field is to be calculated from constants, or from combinations of other fields (including dictionary fields) in the same record. All the usual arithmetic operators are available. After input the only calculation you can request is totalling on printed reports; this is activated by requesting totalling of a field when a description file is set up. Up to 10 fields in any one description file may be set to be totalled.


Protection in Rescue is of two kinds. It is possible to take the programs used in the Define stage off the run-time disk, so that the ordinary user can use file definitions and screen and report formats, but not amend them. At a more detailed level, password protection can be provided for particular data files, for individual description files (so that a user can be given access only to part of the data in a file) or for particular menu items in custom built menus (so that some users may have access to some functions but not others, while other users have greater facilities, but all within one menu). This is a flexible and powerful scheme, and should provide for most needs.

Stability and reliability

I didn’t have any problems over reliability with my use of Rescue. As to stability, new versions of Rescue, which are ‘cost options’, are intended to be compatible with existing versions. New features in the pipeline include a version for MS-DOS and a multi-user version.


As usual, the first task is to tailor Rescue for your particular terminal. This appeared quite straightforward (although, as is the common bad practice, you can’t be sure the tailoring has worked until you actually run the main Rescue suite). However, I had one misunderstanding which I never managed to sort out; this resulted in repeated prompts being printed on the same line as the error messages, which were thereby overlaid so that I couldn’t read the error message. I wasn’t able to discover whether this was an error in the software, the documentation or my interpretation of them and my Sirius manual, but it hasn’t happened to me before. While tailoring for the terminal, you can tell Rescue about cursor movement left and right but not about which keys move the cursor up and down, so much potential editing flexibility is lost.

Once into Rescue, the main tailoring facility is the ability to set up sequences of activities on custom-defined menus. This gets round some of the inflexibilities associated with menu-driven systems, and I found the approach quite easy to use.

Relations with outside

Rescue can write files in standard ASCII characters, using the ‘comma delimited’ format required by many other packages including specifically Wordstar’s Mail-Merge option. Thus you can set up files of information which you want included in circular letters or standard paragraphs, and then fire them off to Wordstar or another similar package.

Within Rescue you can include on a menu the ability to run another program, so it would be possible to tailor a menu to carry out a selection/printing sequence of this kind, called by Rescue ‘record processing’, without the user having to go back to CP/M. You can’t at the moment read external files of ASCII records into Rescue, though there is a menu option to do this already shown, which I’m told will be implemented in the very near future.

User image: software

Once again, your overall reaction to Rescue will be governed by whether you like menu-driven packages or not. I found the ability to tailor menus to provide facilities oriented to particular requirements a big help in mitigating the inflexibilities of menus. However, most users are likely to follow the well-established principle of ‘satisficing (a word coined by Herbert Simon the psycho-economist to describe the tendency to accept adequate or satisfactory results rather than go for the best possible) and only set up extra menus when they absolutely have to, for instance to access alternative screen layouts. So I suspect that mostly people will use the rather cumbersome standard menu facilities. I also had a rather mixed reaction to the complete separation of description of and access to the data files. Within an organisation which has a database administrator (who might simply be the boss in a small business) this could be a useful separation for security reasons, but it would be less helpful where the same person organises the data files and puts information into them, perhaps in a small office, one person business, etc.

Within the package itself, I as usual found some goodies and some nasties. The progress through the menus was orderly and logical and was made straightforward by the provision of the two ‘road maps’ which I show as Figures 2 and 3. The process of prompting was easy to understand. It would have been even easier if, when a question has a default response, this was displayed before the question is posed – in many cases the default is not shown even after you’ve accepted it unless you go back and edit the record concerned. Allowing the use of identifiable abbreviations, both for field names and for data values, is sensible.

I didn’t like the use of row and column coordinates when formatting screen displays and printed reports, especially as there is no default format so you always have to supply one. The ‘paint-a-screen’ approach is much easier in general than coordinate specification and if this is not supplied then there should at least be a default format with records displayed one field per line starting at the left of the screen or paper. I also found the inability to move back within a record when editing a real nuisance.


The manual is basically a reference document but written in so much detail that it could be used to teach yourself about the package if you were reasonably familiar with data management terminology. However, the amount of detail makes it rather difficult to find your way around. Two goodies help a little in this: the use of emphasis within the text to call the readers attention to the most important parts of each section, and the printing of chapter headings right-aligned on each page (a real help to browsing at a general level). But the chapter names didn’t always make it easy to guess where a particular feature would be described, and since there was neither a detailed table of contents relating to each chapter nor an index, it was very hard to get from ‘now I’ve seen something about that feature somewhere’ to the exact part of the manual in question. Part of the remedy is close at hand, since if the ‘road maps’ (which perform most of the functions of a reference card) were annotated with the numbers of the sections documenting each menu item, readers would find it very much easier to locate the particular piece of information they need fast (As this article went to press, MBS issued an index for the manual, which should help.)

The other problem I had was that while each feature is documented in detail with examples of the particular feature, there are no examples of the display or use of groups of features. For instance, all the features of data entry are described in turn, but there is no figure showing how data definitions are displayed on the screen. Nothing bolsters a user’s confidence like some complete examples shown in real screen pictures!

I can’t resist ending this section by awarding MBS second prize so far in this year’s contest for manual typo errors, with ‘Data Validification’.

Costs and overheads

Rescue costs £295, and is available from MBS. To be realistic, you would need a disk system with the regular double-sided, double-density capacity of 370 Kbytes per drive on a two-drive floppy disk system, to enable you to have all the Rescue software on one disk drive and use the other for data I found the system very slow in loading individual program modules, which seemed to happen whenever I changed from one sub-menu to another. I was told that this was specific to the Sirius-Z80 card method of disk access, but I haven’t noticed the problem with other packages I’ve used. The times for actually running the Benchtests are shown in Figure 4. (Details of the tests were given in PCW December 1982.)


Rescue provides data management facilities through individual files. Data description facilities are very powerful. Rescue provides a variety of data types and validation features more extensive than any I have found before. These features also help to make Rescue much more economical on data storage than is usual in programs which use fixed length records. You can select and sort the data to provide pretty well any required subset but the process is rather cumbersome. Screen and report formats can be varied according to the needs of particular users, which makes it straightforward to protect particular data items; you can also permit users access only to certain Rescue features. Screen and report formats are described in a rather rigid way, and there are no default formats for easy initial use.

On the other hand, the ability to send data to and run Wordstars Mail-Merge option from within Rescue could be very valuable in some environments. Apart from the calculation features on data entry, the only calculating power within the package is the ability to total particular fields. The system is menu-driven, which can be ponderous in use, but you can if you wish design your own menus to mitigate this disadvantage to some extent. Rescue is in the main a single-file system – you cannot reference one file through data values in another. Provided this limitation is not a problem, you would find Rescue worth investigating, particularly if the variety of data types and the extensive data validation would be beneficial in your application.

Fig.1. Constraints  
Max no. files in one menu structure 20
Max file size CP/M limit or disk size, whichever is smaller
Max no. records 32760
Max size record 1024 characters (but good data compression methods)
Max no. fields 100
Max field size 60 characters, 14 digits
Max no. keyfields 10
Field types See text – several varieties of character, numeric, date (day/month/year), monetary (sterling), dictionary


Fig.2. ‘Roadmap’ of menus


Fig.3. Menu options

Fig.4. Benchmark times
BM1 Time to add 1 new field to each of 1000 records Setup time
BM2 Time to add 50 records interactively Scrolling time
BM3 Time to add 50 records “in a batch” NA
BM4 Time to access 50 records from 1000 sequentially on 25-character field 1 min 20 secs
BM5 Time to access 50 records from 1000 by index on 25-character field NA* (1-3 secs)
BM6 Time to index 1000 records on 25-character field 12 mins
BM7 Time to sort 1000 records on 5-character field 4 mins 10 secs
BM8 Time to calculate on 1 field per record and store result in record NA
BM9 Time to total 3 fields over 1000 records NA yet
BM10 Time to import a file of 1000 records NA yet
Note: NA=Not available. NA*=Not available as tested – key must match exactly.

 First published in Personal Computer magazine, April 1983


Master Scan


Master Scan is a product in the image of the machine it’s designed for, the Amstrad PCW: no nonsense, no frills, doing the job – and at low cost. But it has one elegant feature, as Justin Moffitt reports: this scanner uses the PCW’s own printer mechanism.

The Amstrad PCW has always been seen as more than just a word processor. Following the introduction of many desktop publishing packages, it is not surprising that Database Software has launched Master Scan, a scanning device. What is surprising is the way it works – it uses the PCW’s own printer mechanism.

Setting up

The Master Scan package comprises: a small interface box to which the scanning head is permanently connected; a manual; the Master Scan software; and some sample artwork to scan.

The manual includes a connection diagram which states that the interface box should be plugged into the serial port; it also shows an artist’s impression of the rear of the PCW with the relevant interface marked. Unfortunately, the PCW doesn’t have a serial port as standard; and the spot where Database claims the serial port is, happens to be a ventilator! The box in fact connects to the expansion port and provides a through connector for other peripherals, such as a mouse.

When you’ve removed the printer dust cover and ribbon, the scanning head can be fitted. This is easy to connect and rests securely on the ordinary print head. The printer dust cover must be removed to allow the lead connecting the scanning head and interface box to move freely.


The Master Scan software loads from CP/M, so allowing you to scan an image and save it for use later. It uses a simple and pleasant system of menus and includes clear onscreen prompts as to what keys to press. The menus are controlled by a highlight bar which can either be moved using the cursor keys, or, for more experienced users, options can be executed with a single keypress.

The scanner menu lets you set the necessary parameters for the image to be scanned. The software allows you to magnify an incoming image by factors of 50%, 100%, 200%, 300% and 600%. The start and finish columns for the scan may also be adjusted to allow a specific area to be scanned. Up to 240 pixel lines may be scanned; then the software asks whether you want to keep or destroy the image. Once you have an image scanned and kept in memory, you can view it onscreen and/or print it out as required.

You may save a scanned image in a variety of formats, including those used by The Desktop Publisher, Fleet Street Editor Plus, Newsdesk International and Master Paint. As you can also load data in any of these formats, the software can be used to convert clip-art between the numerous desktop publishing packages. The disk functions use a powerful file-selector system that resembles the Locoscript disk editor. The drive and user area can be selected, then a highlight bar may be moved over the disk filenames to select a file.

Alternatively, you can type the filename in the standard CP/M format. Unfortunately, Master Scan won’t let you delete or rename a file.

How Master Scan works

Most scanners available at present are flat bed devices that hold a page in a horizontal plane and scan the image line by line, having a specialised mechanism to advance the paper. Database, however, has used the standard PCW printer mechanism to move the page, which lowers the costs without loss of performance. Simple, and clever!

The printer graphics mode is selected to give smooth movement for the scanning head when scanning a page. The head moves unidirectionally, left to right, requiring a second pass to return it to the start position. The paper is then advanced by a small fraction and the process continues until the complete image has been scanned.

When scanning a line, a small beam of light is focused onto the page and the intensity of the light returned is measured. The interface box then converts this measurement into a series of binary codes which are read by the Master Scan software. Using a complicated algorithm to average the incoming codes, a screen image is produced; but, as the PCW cannot display pixels of different intensities, the density of screen pixels is used to emulate grey tones.


Before a page can be loaded into the printer, the scanning head must be removed and the autofeed page function used. The vertical page setting is manual and is carried out with the page-feed knob, whereas the horizontal setting is made from the Master Scan software. Due to the displacement of the scanning head from the print head, the lowest possible starting column is five and the scan must be at least fifteen columns wide. The software makes sure these conditions are met.

A full-width scan for 240 pixel lines, using 100% magnification, took 13 minutes 12 seconds, but most scans will be faster than this because only part of the page will be read.

The scanner cannot read colour material, glossy pages or pages printed using water-based inks, nor can it read anything that will not pass round the printer roller. To surmount all these limitations, Database suggests that you make a photocopy of the material to be scanned. This seems to work perfectly in each case.

The quality of the scanned images is generally very good, although the end result will nearly always have to be cropped and may need superfluous detail removed. I found that near letter-quality text from the PCW printer was not clear when scanned at 100% magnification, but that slightly larger text could be read without difficulty. Images in jet black and white only were best, especially cartoon-type drawings and similar sketches, but the scanner also coped well with photographs.

The external contrast control on the interface box may be used to make the scanned image lighter or darker as necessary but a mid-way setting is fine for most work.

When the magnification is, say, 600%, the unit does not simply scan the image at 100% magnification and repeat each pixel six times, but actually improves its resolution.

Using scanned images…

Images saved from the Master Scan software may be used in many desktop publishing and art packages. The Master Scan software itself does not have any image-editing facilities, so you will almost certainly need another piece of software. Let’s take a look at two in detail.

…with Master Paint

If you want to use your scanned images alone, then Master Paint is the answer. It is a full art program that resembles Mac Paint and uses a WIMP environment that can optionally be controlled by a variety of mice, including those from AMX, the Electric Studio, and Kempston.

The program allows you to scroll the scanned image around a screen window, allowing for images large than the display size. There are icons to draw a line, a box, an ellipse and a polygon, all with the option of using a variable-width pencil. There is also a spray can and a fill tap, for which you can use a pre-defined pattern or define your own. Parts of a drawing may be removed using an eraser. The zoom function is used to show a 16×16 grid magnified by a factor of 64 and allows pixel by pixel editing. There is also an extensive series of block functions, including copy, move, cut and paste. Titles and other text may be added in a variety of fonts and sizes anywhere on the image. Master Paint has a powerful set of disk tools that even includes a formatting routine.

Although the program is more suited to creative art than technical drawings, it is well suited to editing of scanned artwork.

…and with Desktop Publisher

The Desktop Publisher provides a more complete page-design system. The program contains a number of modules called the page editor, the text editor, the graphics editor and the disk file editor, all of which use a series of pull-down menus and – like Master Paint – these can be controlled by a mouse as well as the keyboard.

Although the graphics editor is a little less extensive than Master Paint, it provides all the necessary tools for editing scanned images. Master Scan images can be rescaled upon loading, allowing them to be fitted correctly onto the page. As in Master Paint, there is a pixel by pixel editor and a number of block-editing facilities. Text in a number of redefinable fonts may be made to fit into any area, no matter how large or small.

The completed image can then be positioned on the page using the page-editing module and moved if necessary. Other graphics images and columns of text can be added to complete the page layout.

The end result can be viewed at a fraction of its normal size, then printed either in draft or high-quality mode on the standard PCW printer or an Epson compatible. The quality of the text columns is greatly improved by the fact that they are printed in standard printer text mode rather than being converted into graphics data.

The Desktop Publisher provides the ideal environment for editing scanned photographs and drawings, which can then be directly incorporated into newsletters, and so on.


Database claims that Master Scan can be used as a form of facsimile system, transporting graphics data from one place to another using a modem. The company calls this feature ‘Microfax’.

The Master Scan software has no built-in facility for Microfax and so communications software with a file transfer facility is needed. However, Mail232, included with the PCW, is ideal. Due to the way in which scanned images are saved, there is no checksum facility to warn of corrupt data in the file; this would be helpful in correcting lost or badly-transferred data.

Microfax will probably find little support as a standard since the person or company receiving the image must also have a PCW with suitable software. As a result, Microfax cannot be considered a serious feature of the Master Scan package.


The well-written manual is ideal for quick reference: it lists each menu option along with a clear description of its function and parameters. It also contains some very useful tips on how the quality of scanned images can be improved. For the technically minded, there is a small section on how the scanner works.


Master Scan is innovative and, with relatively little practice, produces good-quality results which can be incorporated into many desktop publishing systems.

Master Scan scores over video digitisers already available for the PCW, as there is no need for extra hardware such as video cameras and lighting; but it does lose out on capture time.

At only £69.95, Master Scan represents excellent value for money. What more can I say?

Master Scan costs £69.95, Master Paint costs £19.95, and the Master Pack containing both costs £79.95. The Desktop Publisher costs £29.95. All available from Database on (061) 456 8835

First published in Personal Computer World magazine, December 1987

A Database by Any Other Name

Paul Myerscough contrasts three information-management systems on his IBM PC.

All may not be what it seems when database systems are under discussion. The accepted definition depicts a store of data with a physical nature that is independent of how it appears to users and application programs. But users of the three systems reviewed here will find that applications often do impose constraints on file design. An alternative definition culled from the Penguin Dictionary of Microprocessors may be more appropriate: it describes a database as “any file which might sound more important if called a database’’.

The names of two of these products are equally fanciful. Tomorrow’s Office, far from being software of the future, is a dinosaur of a system. It is still growing, but how long can it survive? A life-line to the business micro user is the message implicit in the name “Rescue’’. But to reach the market it deserves this package is sadly in need of a rescue itself in the form of an injection of cash for development and marketing effort. Only Delta avoids serious criticism.


All three packages are designed to provide a quick and easy means to develop a custom-built system. Such a system would consist of a set of data files, user input and enquiry screens, procedures for extracting and sorting data, procedures for creating reports, and special menus from which these options may be controlled.

The manuals that accompany the software seem accurate and comprehensive. But they are all too wordy, and they are not well formatted for quick reference. Delta’s comes out on top: at 236 pages it is the shortest, very easy to comprehend, and includes a good, confidence-building tutorial introduction. Rescue’s 408-page manual is far too long and its organisation is eccentric, though an excellent index makes it easy to use; it needs a rewrite.

The most remarkable first impressions come from the form in which the software is delivered. While Rescue arrives on one floppy disc and Delta on two, Tomorrow’s Office requires no less than nine. Over 2Mbyte of program code prompts thoughts of inefficient programming, maintenance and enhancement problems, and the need for disc-swapping dexterity as different functions are used.

Setting up the systems to run on the computer is easy. Tomorrow’s Office has the most polished screen presentation – see the opposite page – while Delta’s option menus and many messages make it the easiest to operate. Rescue has separate programs for data and process definition and for run-time features, and each has its own burgeoning network of menus – see figure 1. A neat help facility provides a short message when ? is entered in response to a prompt.

Figure 1 – One of the two menu networks in Rescue


Rescue uses flat files of fixed-length records which hold up to 1,024 bytes. Each one can cope with up to 10 fields nominated as access keys. Tomorrow’s Office and Delta use a master/transaction file structure with one master field nominated as the access key, which in Delta’s case is sequenced. Tomorrow’s Office allows only 508 bytes to be shared out between a master and transaction definition, while Delta permits up to 2,000 bytes. The maximum file size for Delta and Rescue is around 33,000 master records; Tomorrow’s Office can handle multi-volume files to give 99 times this limit.

The process of defining a data file is prompt-driven. All the systems request entries for field name, type and length, which is a tedious business. It is made worse in Tomorrow’s Office by a requirement for additional screen format data. Rescue is worse still, as it also requires report format data and prompts 13 or more times for each field. Field typing is from a standard set of character, number, or date, with an extended set for Rescue which makes provision for optimising disc storage space and for building in validation criteria.

Database systems are notoriously inept when it comes to changing the format of a file. Delta and Rescue allow a limited amount of restructuring without the need to create a new second copy of the data, and with Rescue new key fields can easily be nominated.

For major reorganisation the standard procedure is to copy fields from records in the old file to a newly defined and empty version. Here Tomorrow’s Office leads the field with the Multi-file option. Delta’s Link and Copy utility offers greater flexibility but requires more effort to use. Rescue has a Loader utility which will do the same for Rescue files.

The first chance to test whether or not a user view is independent of a data file layout comes during screen definition. I was recently involved in the design of a system to handle laboratory test results from customers’ fuel samples. The prime piece of data is a fuel sample with transport/arrival information, laboratory test results and advice data that is sent back to the customer. That one record comes under three sets of fields, each with a different person responsible for updating them. What could be simpler than to provide three different screens to view the same record – one for the logging clerk, one for the lab manager and one for the fuel-quality adviser? Tomorrow’s Office cannot deal with this problem. It provides only one screen view for updating a file. Delta and Rescue can have alternative updating screens and, unlike Tomorrow’s Office, can spread data across more than one screen page.

Rescue provides a unique and useful feature which enables fields to be linked so that their display depends on values entered for previous fields. However, Delta is the outright winner for ease and sophistication in screen-design facilities – see figure 2. The Quick function enables immediate data entry on a screen which is generated automatically from the file description. A custom design is created by painting text on to the blank screen, and escaping to command mode to indicate data field names and display attributes.

Figure 2 – A custom-designed screen created using Delta


Data validation

All three systems allow fields to be calculated from constants and entered field values. However, only Rescue addresses the serious requirement of data validation. For a first-time user it can be hard to grasp that a computer system based on inaccurate or out of date information is no better than a bad manual system.

Consider the simplest case of a field that should contain Y or N to indicate that an invoice is paid. What will happen to an invoice reporting system if the operator has entered H by mistake? Most systems have many fields where only certain values are acceptable. Rescue can associate a dictionary or table of correct values with a particular field which may be mandatory or optional. Numbers can be range checked and, furthermore, format masks may be used. These features are so valuable it is hard to understand why other designers have not followed Rescue’s lead.

For data entry Delta provides a full screen mode of operation, and alone has a useful logging option that will automatically print out the keys of master and transaction records that are added, deleted or updated. Rescue gives a pseudo-full-screen mode of entry, where each field is prompted in its position on the screen and adds its wonderful ? help feature. With Tomorrow’s Office data is entered on the command line as each field is prompted.

All three systems provide a means of selecting records from a file or extract file, and of sorting them into a new sequence. This output may be used for reporting to the printer or screen, and in Rescue and Delta for on-line file browsing too. On-line updating is allowed on Delta only, and batch updating on Tomorrow’s Office and Delta.

In defining selection rules Rescue is the most flexible and logical. Both Delta and Tomorrow’s Office provide rather difficult and limited ways of combining criteria. Delta alone allows some selection criteria to be entered at run time. Tomorrow’s Office has the poorest set of features for sorting data, despite a disconcerting array of main menu options which relate to the subject.

One of the most important features of any database is the ability to print out data. Most people will want a good degree of flexibility in formatting their output: Delta and Tomorrow’s Office run neck-and-neck with the features they offer while Rescue comes a poor third.

Rescue’s standard reports are defined within a file description, which seems unnatural and awkward. The manual puts emphasis on a feature which creates a disc file by merging data and a WordStar document, printing then being controlled from WordStar. This enables easy creation of address labels, standard letters and certain pre-formatted reports.

Tomorrow’s Office and Delta provide a quick route to an ad hoc report using a system-generated layout. For custom formatted reports the features offered are almost identical, and both are more flexible than Rescue. They each have a couple of exclusive features. Tomorrow’s Office allows maths calculations to be applied to data fields before they are reported, and it has a Forms option which eases output on to pre-printed stationery. Delta allows part fields to be printed, some field-editing options, and provides separate control fields for page and sub-total breaks. They both have separate options for creating address labels. Delta provides a useful bonus in its Letter Writer feature, which will merge data with pre-defined text to generate a set of personalised letters automatically.

Many users need to be able to update a file in batch mode without operator intervention, creating a program that will scan a file, recognise a condition in certain records and use what it finds to update some data fields. Delta and Tomorrow’s Office provide a very primitive processing language that can be used on one file to replace the contents of fields with constants or values calculated from data fields, work fields and constants. In both cases the lack of an If-Then type of statement is a severe constraint. Delta is the more flexible, offering the use of look-up tables and an option that reports on the updating that has taken place.

For a procedure not to affect every record on file it becomes necessary first to run an Extract procedure. Different criteria for updating different fields will require several Extract and process runs. This approach is as inefficient as it is inelegant.

All packages can transfer selected data fields from one file to another. This may occur directly in Tomorrow’s Office, and the same is planned for Rescue. Otherwise an intermediate sequential file has to be used. While it is less efficient, the sequential file provides more flexibility as the intermediate file may be operated on by external programs before copying to the second defined file. Delta provides the important ability to update records that already exist in the receiving file. The others allow the creation of new records only.

Custom systems are sometimes required for operators who have no need to learn their way around the whole package. They can be constructed by creating special menus with options that access only the processes required for the system. To print a report might require the selection of a file, the running of a Sort and Extract procedure, followed by the execution of a reporting procedure. They can be combined in one custom menu option with all or most of the required prompt responses pre-defined and acted on automatically. This facility is provided in all three systems, together with adequate password-protection features for screens and files.

What are transactions?

Tomorrow’s Office and Delta use the structural concept of a master file with related transactions. A master data record is accessed by key, and a transaction data record is accessed through the master. Figure 4 shows the one-to-many relationship of a master record to its transactions. This useful concept meets some of the needs of applications by storing data just once in a master record and by providing a variable amount of repeated data stored as transactions.

Figure 4 – Master/transaction files structure as featured in Tomorrow’s Office and Delta



By allowing up to eight types of transaction, Delta provides a structural path from one type of data to another. With only one transaction type, Tomorrow’s Office cannot offer this important feature. The ability to relate a transaction to more than one master file would allow the design of a flexible network-type database, but neither system allows this.

Both systems provide a means of updating a master automatically when transactions are added, so a new Order transaction may cause the Quantity Available to be reduced in the master record. When data is viewed, a fixed portion of the screen is allocated to master data with a separate area at the bottom of the screen for transaction data, as in figure 3. In the lower portion transaction records may be scrolled, while data in the related master remains in place. This is less inconvenient with Delta, as alternative updating can allow more or less space for each type of data.

Figure 3 – Multi-file options and file definitions




The option menus and many messages provided by Delta make it simple to use.

Delta is a package that is professionally produced and easy to use. It has a range of features designed to equal or better most of the competition. Its design shows an appealing degree of flexibility, and progressive enhancements should keep it alive for some years.

The master-file/transaction-file structure has much to recommend it. At the conceptual level it provides a first step towards the development of a real network of database files. Allowing eight transaction types is fine, but it is disappointing that only one can be accessed at a time; when using this type of structure it is natural to need to use more.

Another disappointment is the limited Process facility, which could at least be enhanced for use in validating input data. The Link and Copy facility is simple in concept, but it is good and flexible. It scores well for the data-entry logging option and for the ability to update records using an extract index.

Delta is well placed for a successful ride in the market-place. The fact that it is being distributed by IBM, DEC, and Xerox must be regarded as a recommendation.

Tomorrow’s Office


This product rose to fame with the Sirius computer, and caters for many of the file-processing needs of its user. It uses a master/transaction file structure and has fairly attractive development screen displays which consistently prompt for entries on a command line at the bottom of a screen.

Its range of functions allows Tomorrow’s Office to maintain its position in a feature-count with the competition. It is the only package among those reviewed that allows more than one volume of data, giving an almost unlimited file size. Multi-file allows secondary file look-ups and updates and is a feature worth having. It is not yet offered by Rescue or Delta.

Tomorrow’s Office has grown so large that it is no longer usable on a small floppy-disc based system; changing program discs all the time soon becomes unbearably tedious. It is limited by a record size which cannot exceed 508 bytes for master and transaction combined, and more seriously by the fact that any master/transaction pair may only have one updating screen. No provision is made for the validation of input, and many features are not as complete as their equivalent in Delta.

Many data-processing systems contain information which is duplicated in different files, and it is here that the relatively new Multi-file option comes into play. When adding records to a main file, predetermined fields may be Filled from data held in a secondary file. Likewise, data from the main file may automatically be Put to a secondary file to update it. These two processes Fill and Put, are in essence what Multi-file offers.

Multi-file uses windows in the creation of a process, as shown in figure 3. Some will contain processing options, while others may be scrolled across file-definition data. Most Multi-file processes can be defined simply by correctly positioning the cursor and pressing Enter to select both options and field names.

The limitations of Multi-file are largely those of Tomorrow’s Office itself. It provides scope for handling data from several files at once, but only in the context of the 508-character main file. Data which is not stored in the main file or transferred to it cannot be accessed or displayed, and there is no real conditional processing at the field level.



Rescue, a flat-file based system, has been implemented on over 40 different micros. Its features show that it has been produced by people who know the problems of applications system design.

The attention to data entry is outstanding. Validation of input is vital if a system is to function effectively, and only Rescue caters for this need. The Link feature addresses the problem allowing alternative fields to appear on a screen. The ? help facility, which is sensitive to predetermined validation rules, will prompt the user for data in the correct format. If “word processing” and “database” are designated as valid entries for a field, only w or d need be entered and the system will fill in the rest.

The reporting facilities are rather weak, and a batch updating option is needed. It may be added in a future release. The ability to update one database file from another will enable Rescue users to break out of the restrictions imposed by operating on only one file at a time.

There is a need to tidy up this system if it is to break into the IBM PC market-place. The manual must be rewritten, the multiple menus tamed, and screen and report definition should be unbundled from the file-definition process. Some additional features would place it ahead of its rivals in user image. Rescue is a potential prince for its type of software, currently wearing pauper’s clothing.


  • All three systems provide the means for a user with no programming knowledge to generate a working file-based system.
  • All provide a spread of equivalent features, and they appear to be average to good in terms of execution times.
  • Many basic features offered by a programming language are missing, and there are no interfaces for use by external programs.
  • Simpler systems are well suited to this kind of package, which will save up to 85 percent of development cost over using a conventional language.
  • Delta is the package with fewest faults, and is the easiest to use; it beats or equals Tomorrow’s Office in almost every area.
  • If you do not need a master/transaction file structure Rescue may be worth considering; despite its rough edges it has some unique and valuable features.

In brief

Runs on: IBM PC and most MS-DOS micros
Minimum memory: 256K
Supplier: Sosoft Ltd, 300 Ashley Road, Upper Parkestone, Poole, Dorset BH14 9BZ. Telephone: (0202) 735656
Price: £595
The system under review included the Multi-file option; the Standard version costs £395, and a Junior version is available at £195.

Runs on: CP/M-80, MS-DOS, PC-DOS, PCOS
Minimum memory: 52K TPA
Supplier: Qudos Systems Ltd, 5 Charterhouse Buildings, 27a Goswell Road, London EC1M 7AN. Telephone: 01-253 3998
Price: £295

Runs on: IBM PC, MS-DOS, CP/M
Minimum memory: 128K under MS-DOS; 64K under CP/M
Supplier: Compsoft Ltd, Hallams Court, Shamley Green, Guildford, Surrey GU4 8QZ. Telephone: (0483) 898545
Price: £495

First published in Practical Computing magazine, April 1984