Nash - Scientific Computing with PCs (523165), страница 16
Текст из файла (страница 16)
When we network machines, we let this process to be taken to its logicalconclusion. When we work on exchangeable media such as diskettes, we can create pairs of diskettesfor security but keep them organized in the same way.•Listings of all data and programs in a given application area can be kept in a binder. Such listingsshould be dated. Changes can be noted on the listing, with the appropriate date. When the listing isheavily marked, it can be replaced. Old fashioned though paper may be, its human readability isself-evident, and the listing serves as both a documentation aid and a security backup.
Listingprograms should print the time and date stamp to help the above process.•Unidentifiable files should be deleted.•Users should choose a naming convention to identify temporary files that, if found in the system, canbe erased without concern for their contents. Examples are files with the extension. TMV, or any filesthat start with the letters TEMP.40Copyright © 1984, 1994 J C & M M NashSCIENTIFIC COMPUTING WITH PCsNash Information Services Inc., 1975 Bel Air Drive, Ottawa, ON K2C 0X1 CanadaCopy for:Dr.
Dobb’s Journal•Programs that create temporary work files should automatically delete them at the end of successfulexecution. We wish all commercial vendors would note this recommendation.•For programs under development, users should consider using working disks or directories that arekept separate from the main file ensemble, or else using RAM-disks.•The use of archiving programs to save the entire set of files at a given point in time can be helpfulif we need to keep versions. This reduces the problem from one of maintaining version records forall the files to that of keeping track of the (dated) archives.5.7Loss versus SecurityLoss of information contained in the file ensemble is the ultimate fault that we would like to avoid.
Most,though not all, causes of degradation of the file ensemble are human in origin. Rarely do machine errorscause loss of information already successfully recorded.Failure of the disk controller is unlikely to be only in the write circuitry. Moreover, read-after-writeoptions are available on most systems and should be used to detect either drive or disk media faults (e.g.,scratches).Some of the ways in which human error can lose information follow.•We record data on the wrong disk or forget to record it.•Disks are handled roughly or we allow dirt and dust to accumulate.•We make programming errors that write incorrect data.•We are forgetful and fail to backup files immediately or fail to destroy unwanted files thereby creatinga source of confusion.•We reformat a disk containing wanted information.•We commit a typing error that deletes data or copies from "old" to "new" during backup, therebynullifying an update.There is no magic cure for file degradation.
Every user makes some mistakes in learning how to use hisor her system effectively. Anyone who has accidentally erased a file built over much time and with mucheffort knows how much that experience teaches of the value of caution thereafter.To our list above we add the possibility of intentional damage to our data. This can arise by virtue of:•Vandalism or theft, that is, physical damage or loss of equipment;•Intentional alteration of data for whatever motive;•Damage by computer viruses, that is, programs designed to cause nuisance or destruction.We do not consider intentional destruction to be a major threat to scientific users of PCs, except forcomputer viruses. Viruses have become a large issue because of the general practice of moving diskettesfrom machine to machine in an uncontrolled manner.
Control requires appropriate discipline.•It is useful to scan all diskettes that have been in "foreign" machines with a program that looks forcommonly known computer viruses.•Fixed disks of software can sometimes be write-protected, for example using our SnoopGuard device.Unfortunately, some operating software makes this difficult to do by requiring write access to severalconfiguration files.•Programs can be used that continuously monitor the system for suspicious activity.5: FILE MANAGEMENT•41Programs can be run periodically that check for changes characteristic of the behavior of viruses.All the above relate to detection of viruses.
The only sure fix after detection is restoration of files frombackup. Hence good backups are essential.Security against unauthorized access can be accomplished in several ways. First, we recommend goodconventional physical security. Doors have locks, as do filing cabinets, and they should be used if thereis a risk of unauthorized entry. If machine use is a problem, there are a variety of hardware devicesavailable that require keys, access cards or passwords to be used before part or all of a PC’s resources canbe used. Our own product (SnoopGuard) is an example of a password access control device.
It also allowsfor screen blanking with password restore, a feature we believe is useful in environments where usersmay need to prevent information (e.g., medical or personnel files) from being seen by unauthorizedpersons.Logical methods may also be used to prevent access to data. Files may be encrypted or otherwise lockedin some way by the software that permits access to them. The DR DOS alternative to MS-DOS incorporatessuch a feature, but it is easily defeated. Several database packages let files or records be "locked".Encryption of a file is more secure, but our opinion is that it causes rather than prevents loss of data whenusers forget the "keys" or passwords to undo the encryption.
This is even more dangerous when accesscontrol is implemented by encrypting the directory tables of a fixed disk. We have heard of several caseswhere physical errors, forgetfulness or disaffected employees have caused loss of the encryption keysleading to the loss of all data and programs on a fixed disk.For data that must be kept secure, we recommend removable media. This may be as simple as usingdiskettes. Alternatively, several vendors offer high capacity removable disk drives that behave inessentially the same way as regular fixed disks. The removable media can be secured by regular lock andkey methods.A security measure that is often overlooked is the procedures manual. This is no more nor less than asimple booklet of rules or standards to follow.
By providing simple steps to follow for file system backupand a regular schedule for so doing, a procedures manual forces a small amount of order on an otherwiseundisciplined situation. We recommend the practice. Alternatively, the instructions for several commondifficulties can be pinned on the wall or a cork board so they are readily available.
Of course, if not used,these measures are a waste of time.Previous Home Next42Copyright © 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 JournalChapter 6Programming6.16.26.36.46.56.6Programming tools and environmentsCross-reference listing and data dictionaryFlowchart or other algorithmic descriptionStructure and modularitySub-programs — data flowProgrammer practicesWe now consider general ways to make programming easier.
These mainly concern programming style,especially where memory space is limited or special resources of the machine must be used for reasonsof speed or other necessity. While scientific computations are increasingly performed without traditionalprogramming, users must still bring data and algorithms together in an appropriate way. This is still aform of programming and the ideas of this chapter generally apply.6.1Programming Tools and EnvironmentsScientific computing, because it often involves new ideas, can require new procedures or arrangementsof procedures. In the past this has implied that scientists have had to learn "computer programming" inthe traditional sense of procedural programming languages.
Much scientific computing still involves thewriting of code in FORTRAN, C, Pascal or BASIC, but increasingly scientists are working withcomputational environments more suited to their particular needs. These allow large blocks ofcomputation to be performed at a single command, and integrate many graphical, statistical, numeric anddata management tasks in convenient packages.There are now many packages in use for statistical analysis, engineering analysis, forecasting, solution ofdifferential equations, signal processing, image enhancement, and a host of other computationallyintensive subjects. While these overcome the need for the user to program the detail of the computations,any package that allows the user to issue a sequence of commands is being "programmed".
Packagesrequiring the user to issue commands one at a time from a console, without the possibility of executionfrom a stored script, are of limited utility. Such packages cannot be programmed; the user must rememberand enter the commands, thereby working for the computer rather than vice-versa.Many computational packages even present themselves like programming languages, for example, mostof the major statistical packages, the matrix language MATLAB, or the modelling software GAMS.MINITAB even allows the commands of an interactive session to be automatically saved (by theJOURNAL command) for later re-execution. Here the important aspect of these packages is their capabilityof execution under the control of a command script, even if there is an interactive capability to let us testideas in a quick "walk-through".The idea of scripted calculations can be carried further using various mechanisms for stringing togetherexisting programs.
In the MS-DOS environment, we have the BATch command language to automatecommands. Various mechanisms exist to enhance the MS-DOS batch commands, including "compilers"that allow faster execution and the invocation of one string of commands from another. We have beeninterested in hypertext scripts (Nash, 1990b). Hypertext processors of various types exist on all commoncomputing platforms.
Unfortunately, there does not appear to be a scripting language to tie togetherexisting programs that is platform independent (Nash, 1993a). Sometimes we can use traditional6: PROGRAMMING43programming languages to launch executable programs.Another way to glue together preprogrammed computational building blocks is to use a subroutine libraryand write the "glue" in a regular programming language that can call the subroutines easily. This is atime-honored approach in scientific computing. It is well supported by commercial and publicly availablecollections of routines, particularly in FORTRAN.Whatever route we decide is appropriate, it is important to have available tools to support the writing andrunning of the programs we create. Convenient and reliable tools save us much time and effort.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
