Nash - Scientific Computing with PCs, страница 14

To this end,we use our own small program (Pdate.pas) that displays the date and time in a format we findconvenient. That is, we like to see:Current date & time: 1991/7/216:46:30.36Note that the date and time follow the ISO forms yyyy/mm/dd and hh:mm:ss.xx where xx is inhundredths of seconds. The clock in many computers is not capable of 1/100 second precision, butconversion of the fractions of a second to this form is convenient.We often use redirection to put a time stamp on diskettes. For example, we can use the command5: FILE MANAGEMENT35pdate >A:timedate.dskto put the current date and time line above into a file called TIMEDATE.DSK on the diskette in drive A.Few computers have operating systems with integrated file management, where the catalog iscontinuously on line and dynamically updated.

(The only one we have used was the GEORGE 4 operatingsystem of the ICL 1906A computer in the early 1970s.) This reflects not only a limit on the physicalresources - the size of the catalog of files may be too large to be kept continuously available ("on-line")— but also the organizational difficulty of registering changes to volumes that are not attached to thesystem. Users may take disks to other machines and add, delete or modify files there. How can we controlor monitor such activity?Operating systems do, however, provide the user with the capability to list the contents of a singledirectory on individual storage volumes (disks). How, then, can a consolidated catalog of a number ofdisks be made? Clearly, each filename must first be associated with the volume (we will use disk andvolume interchangeably) on which the file resides, so disks must each be given a unique name or number.We may also want to note the subdirectory in which a file is found.Thus the contents of each disk must be read, directory names extracted, filenames extracted and linkedto directory names to make a full filename, and the unique disk identifier attached to each full filename.This list of extended filenames must then be sorted and displayed, with the short filename being the mostlikely sort key.This task may present the user with several obstacles.

First, the individual disks or tapes may have nounique identifiers if users omit to label disks or else supply non-unique names. Second, there may be noeasy-to-use mechanism that allows the directory of an individual disk to be read as data by a programsuch as a cataloguing utility. In our own work we have made use of the operating system DIR insidebatch command files rather than develop hand assembled machine code calls within programs. Once thedata has been collected, the filename sorting and display must be done carefully so that duplicate namesare easily recognizable.To complicate matters, a single computer may be operated under several operating systems, each of whichuses different conventions for storing the catalog directory of a disk.

For example, both IBM PC class andApple Macintosh family machines can be operated under variants of the UNIX operating system as wellas their own flavors of system software. If we are running two different operating systems, we are forcedto fragment our catalog.

Unless there are very strong reasons for running more than one operating system,we recommend that only compatible operating systems and compatible versions be used within a singlegroup of machines.Our mention of versions raises "within family" differences. On the Macintosh, the System 7 FINDER onthe Macintosh is different from previous versions.

On IBM PCs, there are both generic (MS-DOS) andproprietary (e.g., PC-DOS, Compaq DOS) variants, and these all have a variety of versions.We have felt strongly enough about catalogs to have developed two cataloging utilities, one for North StarDOS (Anderson and Nash, 1982) and one for MS-DOS machines (Nash J C and Nash M M, 1989).Programs that purport to do similar tasks exist in collections of shareware, but we have not seen anymajor commercial catalog program.We note that a major reason for listing all files (with attributes such as length and time stamp) is that wewish to eliminate duplicate files where possible.

Special programs exist that are designed to help in thistask, but the catalog is a good starting point, since duplication may occur in the name rather than the filecontents. Only the user can decide what files are to be eliminated and what ones kept. In some case wemay need to run file comparisons to decide where the differences lie.

We note that saving a file to thewrong directory is a frequent cause of multiple versions of a single file.Catalogs of files take time to build, especially if we include all the removable volumes that accompany36Copyright © 1984, 1994 J C & M M NashNash Information Services Inc., 1975 Bel Air Drive, Ottawa, ON K2C 0X1 CanadaSCIENTIFIC COMPUTING WITH PCsCopy for:Dr. Dobb’s Journala computer or group of computers. In our own work we have found our use of catalogs decreasing withthe linking of our machines into a network, since this simplifies our storage of files.

One and only onemachine is used to hold each group of files, for example, the material for this book lives on a machineidentified as JOHN on a particular fixed disk drive and in a special directory. All faxes live on a machinecalled FAX.5.4BackupWe try to maintain two backup diskettes for each directory containing our own files. About four timesa year we do a complete backup to tape to preserve the files and associated directory structure.

This isa form of insurance against accidental loss of the information we are likely to want to use again. Somecauses of loss of information are discussed in Section 5.7. Unfortunately, the fear of information loss leadsmany PC users to make too many copies of the same material. (We are culprits too!) During programdevelopment, one may save trial versions of programs, thus keeping several similar, but not identical,program files. Data files, too, may exist in multiple versions, for example, the manuscript of this book asit is being revised and edited. Later we consider version control methods.

Here we concentrate purely onbackup.The first requirement for the security of copies of files is that they be somehow physically distinct. Forfloppy disks, this means two disks. For fixed disks, copies may be made to a sequence of removable disksor tapes. It should be noted that many PC systems have a single physical fixed disk that is partitionedinto more than one logical disk for organizational convenience. We do this ourselves to let part of ourdata to be write-protected.Once a file exists on two separate physical objects, we need to think where we are going to keep them.For safety against fire, flood and other perils, the two copies should be in different locations, possibly inspecial containers to protect them against shock, dirt, moisture, heat or stray electromagnetic radiation.Of course, when updates are to be made, we may have a long walk to fetch the disk or tape for revision.In our own work, we usually accept the risk of storing short term backup files in our office.

Originalcopies of our operating and commercial software or data are kept in a relatively inaccessible "master set"of disks out of normal reach. Disks in the "master set" generally have the write-protection mechanismengaged. For files that would be difficult to replicate from other sources of information, we keep a copyin our "security set" in another office at a different location.Some readers may be unfamiliar with the write-protection that exists for practically all magnetic recordingmedia. This is a physical mechanism to prevent writing, though reading is still allowed.

For example, oncassette tapes there are small square tabs that may be broken off to prevent recording. On half-inch tapea write-permit ring must be inserted in a groove in the reel. 5.25 inch floppy disks use a notch that iscovered to write-protect the disk. 3.5 inch disks are protected by opening a slider on a small squarewindow.Carrying out the backup is the most dangerous step, because it may involve having both primary andbackup media (disks, tapes, etc.) in the machine simultaneously. For example, a power failure while bothvolumes are being accessed could cause physical damage to both. There are ways of organizing thebackup to minimize such risks, but at the cost of more complexity for the user.Backup should, where appropriate, be built into programs.

It is easy to add a small amount of code tomost programs that presents the user with a series of instructions to make a backup copy of data files.An example dialog might be:Machine: DO YOU WANT A BACKUP OF YOUR DATA (Y OR N)?User: YMachine: TAKE YOUR DATA DISK OUT OF DRIVE 1, PUT IN BACKUP DISK. ARE YOU READY?User: Y5: FILE MANAGEMENT37Machine: COPY MADESome programs always make a backup copy of a file. This can be a nuisance and fill disk spaceunnecessarily.