Previous Table of Contents Next


Workpaper A-61
Effective Data Processing Control Practices

No. Description of Effective Control Practice
  CONTROL AREA: DESIGN PRINCIPLES
1. Concentrate Change Activity. When a data record is being updated during a file processing application, the application code should be locally structured so that it does not make any changes to the record until all tests have been passed and the transaction can be posted. Therefore, in the event that an error prohibits an update, the original record need not be reconstructed. This technique also minimizes the probability that an abort would leave the database in an inconsistent status.
2. Improve Data Quality. Although item counts and hash totals are effective controls, the primary controls over a database should be selected from fields that are totaled and presented on the system’s major reports; that is, the totals should be meaningful numbers used by the system’s human monitors for work load, trend, financial, or value analysis.
3. Use Standard Data Elements and Codes. Once the database concept is understood and integrated files are contemplated, MIS management usually appoints a database administrator. Typically, some responsibilities are transferred from the programming and operations departments to the new database administrator.
Shortly after the appointment, the database administrator establishes procedures for the data file design and definition process, followed by standard file formats, record formats, data element formats, and local standards for encoding some data element values.
These local standard encodings eventually give rise to common tables of values shared among application systems. A single common utility program under the control of the database administrator maintains these tables of standard values.
4. Perform Context Edits. Edits on individual fields in isolation are less powerful than edits on fields in combination, because the latter are performed using recent history from fields and records already processed on the current computer run. For complex edits dealing with a sequence of input, as in an online dialogue, a structured edit tree should be built and specific tests should be made dependent on what has gone before. Strings of fields containing a structure can therefore be verified for reasonableness using an edit structure.
For example, the response to the question “How many persons in your immediate family?” could be edited in isolation only as numeric, between 1 to 20. A follow-up question, “What are the names of the persons in your immediate family?” allows the two responses to be processed in combination. A programmer might be uncertain whether a response of “one” to the first question included the person being interviewed. A higher confidence level is achieved if the number of names matches the population count.
If default options are used in conjunction with a complex context edit, the defaults inserted can be conditioned by the point in the edit tree at which the default is invoked. For example, a blank field could receive different default values based on different contexts.
5. Perform Staged Edits. This can be illustrated by the following example. The design for a large system that involved a high volume of complex high-value input included minicomputers controlling clusters of keyboards and batches of transactions being sent online to the central data processing system. The edit concept called for four discrete stages of editing:
• The first edit was a field edit. This was performed online in real time. Following each end-of-field delimiter, the field was checked against the field specification for length, character set, and value range.
• Following the last field in a record, the record was checked against the record specification to determine whether the fields existed in legal combinations for the record type and, when possible, whether the collection of fields in the record was a legal set of fields containing individually legal field values that constituted a legal value set.
• After a group of records was completed by an individual operator, the batch was checked for batch consistency against a batch specification using the background partition of the minicomputer (operating under the control of the keyboard supervisor) before the batch was released for central processing.
• Finally, when received by the central computer, the batch was edited for format, content, and context, and all encoded variables were verified with the appropriate authority list. Incorrect or questionable records were flagged to inhibit further processing, passed through the system, and eventually printed for final resolution. All of the errors found on the batch were kept together as an error batch and printed on error worksheets in the same sequence as they were received (to assist in matching errors and original documents during the resolution process).
6. Use Restart Logs. It is a common practice to log input transactions during a database update. With the advent of inexpensive file storage, the logs have been specified to contain the “before” image of the data fields destined for change, and the “after” image of those same fields. It is therefore possible to rapidly recover the modified files by loading the data set produced during the last checkpoint dump and avoiding the cost and time penalties of reprocessing by simply replacing all before images with their companion set of after images from the log.
In addition, if a sequence of transactions ends in failure and leaves the database in an unusable state, it is possible to reverse the effect of processing and replace all after images with before images back to the point of the first transaction in the erroneous sequence.
If input transactions are sequentially numbered and logged on the same log with the before and after images, and if the sequence numbers appear in the before and after records logged as a byproduct of the update process, it is possible to tie a transaction to its related updates and therefore recover from a failure with transactions in process. (Such recovery requires a selective backout of changes to all records affected by the transaction in process at the time of failure.)
7. Use Default Options. Default options are a reasonable way to fill in missing data elements or to correct erroneous element values where the processing context allows the correct value to be known to the program.
When life or severe catastrophe is at risk, however, default values should not be used. If the critical process is online, safety considerations should require that the terminal keyboard be locked and that the computer insist on perfect data with all exceptions positively acknowledged (i.e., no assumed or default data values).
8. Take Equipment and Screen Design into Consideration. The design of applications involving keyboard entry requires a careful appreciation of the human factors involved. The system designer must be familiar with the data and its various formats, the equipment to be used, and the environment (including workstations, lighting, and sound conditioning).
Properly supervised professional data entry personnel may use heavy abbreviating to cut the keystrokes required. If the volume of input for a specific application is not sufficient to provide full-time employment for several operators, however, the designers should be wary of excessive abbreviations and any form of code compression at the input stations. Instead, the designer should provide alternative input sequences and varying codes for different levels of training, experience, and skill. These must be combined with a set of supervisory statistics that allow each operator’s throughput to be measured against an appropriate skill classification. (The designer should beware of simple statistical averages because these push unskilled operators beyond their capability, resulting in error cycles.)
CONTROL AREA: FILE STRUCTURE
9. Add Quality Flags. Data quality flags can be added to files, records, groups of fields, or individual fields in a database and can be used to condition processing to avoid a mismatch between the quality of the data and its intended use.
Every record can carry a quality flag. The flag indicates to each processing program which format and content checks the record has successfully passed. The quality flag should be the first field read by an application program and the last field written by an update program.
10. Use Activity Dates. If each input transaction carries a date-of-event and each record in the file carries a date-of-last-transaction-processed, these two dates allow processing to be performed in the proper sequence (or manual intervention to be requested) in case of transportation or processing delays.
11. Ensure Reliability Through Batch Redundancy. Hash totals and item counts ensure that batches retain their integrity through multiple transformations (i.e., editing, sorting, updating, and printing). Item counts should be carried completely through the process to ensure that every item is processed. This has long been a common practice in some industries.
The primary key used in file maintenance should be a unique numeric identifier carrying a check digit. When this is not possible, partial protection can be achieved by check summing (hash totaling) numeric key fields so that a batch of data maintains its initial integrity through all processing. It should be noted that check digits on ID fields and check sums on both records and batches constitute specific practical examples of added redundancy in the input stream. They increase the character count to achieve improved data reliability.
12. Ensure Reliability Through File Redundancy. Some file systems carry check sums into the database to ensure that data quality does not deteriorate over time. More advanced systems carry separate check sums—one for the control information and the other for the data values.
13. Ensure Reliability Through Input Redundancy. Additional redundancy can be built into input messages (at the cost of increasing the input character count) to provide context information for edit programs and to facilitate meaningful correction and operator dialogues. This redundant information takes several forms: check words, double entries, check digits, and batch totals.
14. Provide Redundancy for Audit. Within the database, additional information can be carried in the record header to provide the basic parameters for certain types of integrity audits. Specifically, a record header could contain the identifier associated with the last program to update the record, the date of that last update, the time of the update, and the transaction sequence number causing the update.
15. Use Date Checks in Sequence. During input processing, the effective date of the transaction can be processed as well. This allows the control group to identify old transactions and can inhibit their processing. When the effective date of the transaction is compared with the effective date of the last to update a data record, out-of-sequence transactions can be recognized and manual intervention can be requested.
16. Design Self-Defining Files for Integrity. One technique for handling very large files (e.g., those taking at least a dozen full tape reels at 1600 bpi) involves designing files with directories on the front of every individual record. The directory describes the structure of the record and contains pointers to every data element contained in the record. Not only does this record format make files independent of the application programs (and therefore insensitive to changes on these programs), it provides extensive redundancy and allows the integrity of the large files to be audited and maintained.
Key features of these techniques are:
• A master dictionary defining all data elements in the system and awarding each data element a unique ID number.
• A record format that provides for a directory on the front of every data record. (The directory should be of variable length and contain one four-byte entry for each data element in the record. The first two bytes are the data element ID number, the third byte is a pointer to the beginning of the related data value in the record, and the fourth byte is the length of the value field in the record.)
As each program is loaded, it references the dictionary and provides the names of the data elements it plans to process; in return, it receives current descriptions, edit specifications, and ID numbers for those data elements. Then, when each individual record is read for processing, the data element ID from the directory is used to locate that data element and invoke the correct edit specification.
A variation of this scheme provides a structure in which records always grow through the addition of new information and no information is ever deleted; only the pointers change. If correction is ever required, the old pointers are retrieved from the log and restored to their previous values (the data still exists in the records). This technique is most appropriate for standing master files of data with low rates of change.
17. Use Variable Names to Enhance Edit Logic. One set of data management software stores the variable name adjacent to each occurrence of the variable. Although the storage space is increased, the name/value pair provides helpful redundancy for editing and lays the foundation for two stages of table-driven editing: one as the data is received, and the second immediately before the update. The update edits are used to test the validity of an input variable; compare it with other input values, stored values, or literals; and derive a replacement, ’sake appropriate cancellation action, or accept the value as input.
If variable names appear in the input stream or are appended during input processing, they can be carried with the variable throughout the system. Then whenever a variable reference is required, the names are matched and the machine address of the adjacent data value is computed at the instant of reference. This provides a degree of independence between the program and its data. Furthermore, if the names do not match, an error routine can be called before erroneous data is introduced for processing.
Although the permanent storage of named variables may increase file sizes disproportionately and therefore may not be able to be used in the database proper, the use of named variables on input and during preliminary processing provides a degree of flexibility in free-form input coupled with important editing enhancements for the price of a few additional characters in the input stream. This scheme can be contrasted with a highly efficient but unforgiving input format in which variable recognition in the input stream is based solely on its position.
18. Use Software with Restore and Reprocess Functions. Some data management software has before and after images stored on the log tape. In addition, a RESTORE verb allows applications programs to request that the files be restored to a previous checkpoint. A REPROCESS verb allows application programs to request that a limited sequence of transactions be reflected in the file to a transaction previously found to be in error.
19. Provide Self-Defining Files for Audit. An advantage of a file design that has a directory on the front of every record is the ability to validate the record after the update by using the transaction type code from the input and the database description, including the data element dictionary and the resulting record structure. It can then be determined whether all required data elements are present and all present data elements are permitted.
Whenever a group of input fields routinely appears together, the group can be given a single identifier or transaction type code. This code may explicitly appear in the input record along with the group of fields that it names. This group name can be used to enter the database description so that the data editing specification can be obtained for the group. The desired structure of the input record can then be verified against the specification and the following determined:
• Does each data element meet its specification?
• Does the record match its structure?
• Are all the required data elements present?
• Are all present data elements permitted?
In a similar way, the file can be verified at the time of the update or any later time. The file record would have a type code, and the record specification could be obtained from the database description. Each record could be individually verified and the collection of data elements in the record could be checked for presence and structure.
CONTROL AREA: FILE CONTROLS
20. Program Read-Only Status. When the correctness of basic records on master files of essentially static data has been established, a flag bit should be set in the record header to inhibit further update without special privilege. If an installation-standard file access method is used, this bit inhibits unauthorized updates and maintains the integrity of the basic data.
21. Build in Redundancy for Post-Audit. After a database has been designed, the design should be reviewed and, when necessary, redundancy should be added to allow an audit program to verify the integrity of the file set. The audit program can then be run to prevent the data in the files from deteriorating unobserved.
For example, the first level of detail in a payroll file provides a record on each employee. A second level summary record is provided for each department and the summary record contains a count of the total number of employees assigned to the department (item count), the total of the base salaries for all employees assigned to that department (control total), and an arithmetic total of all employee telephone numbers (hash total). Whenever the condition of the file is suspect, an audit program could verify that the detailed records summarize to the department totals. Just these few redundant control fields provide a fair level of confidence in the integrity of the file. Additional control fields of redundant information can be added to increase the degree of confidence.
22. Use Segmented Controls for Efficiency. Most databases have two or more processing patterns over a full processing cycle. All database programs should maintain control totals although they may process transactions in random sequence. Any sequential processes should perform a complete verification of the parts of the file they process. The file controls should be segmented so that any sequential process handling part of the file can have access to control totals for just the part of the file routinely processed.
In the payroll file example given in Item 21, in a disk-oriented database system, the department summary records would be kept in a file separate from the detailed data. When the pay file was referenced during an update, the appropriate department summary could also be updated. If the database design allowed individual summary records to be referenced, the maintenance of summary records would be inexpensive, yet they would provide necessary redundancy; an audit program could be called at any time to verify the file. The summary records should also be designed to provide statistical data useful for management reports.
CONTROL AREA: PROCESSING SEQUENCE
23. Provide Operator Feedback. For online systems, the computer should positively acknowledge each transaction by assigning sequential message numbers to the transactions emanating from each individual terminal. A new message is awarded the next consecutive number and a positive confirmation of receipt displays that same number to the terminal operator. This number provides transaction accountability, and in the event of restart, the operator can use numbered transactions to determine which transactions to reenter.
Ideally, messages should be hash totaled by an intelligent terminal before transmission. If the terminal does not have this capability, the hash total can be appended by the first intelligent machine-controller, multiplexer, or host that handles the message.
If messages originating in the host computer and directed to individual terminals are also numbered, the operator can ensure that no messages were lost in the communications network.
Similarly, if the host develops a hash total for the outbound message and if that hash total is verified by an intelligent terminal as the message is displayed, the system can assure the operator that the messages are delivered with the content unchanged.
24. Use an Immediate Edit, Deferred Update Procedure. One large database system collects input transactions during the day, edits them, stores them in a batch, and reflects the entire batch of transactions in the file during one massive overnight processing run. The system attempts to guarantee that transactions entered during the day will be reflected in the file that night by thoroughly editing each transaction online before accepting it for the overnight queue. Unless the transaction is incompatible with the database (e.g., attempts to change a master record that does not exist), the overnight processing will be successful.
25. Concentrate Update Activity. With a database containing redundant information in several files or an integrated database that has redundant information in secondary indexes, multiple accesses are required to complete a single transaction. It is useful to establish a programming standard to minimize the risk of creating an incompatible file set as the result of an abort during update processing. At the risk of adding a few file accesses, all reading of all files can be accomplished before processing and all changes to all files can be collected into a single compact write sequence following processing (i.e., reads and writes should not be distributed uniformly across the processes). Concentrating the writes reduces the probability that a processing failure will prohibit the sequence of writes from being completed and leave the file set in an incompatible state.
CONTROL AREA: PROGRAM STRUCTURE
26. Avoid Interpretive Change. Some programs unintentionally modify more data than they should; in an integrated database, storing a field one byte too long destroys the adjacent field. A table-driven interface module can be appended to the record fetch routine supplied by the database management system. A program can obtain any data needed but can return only the data that it is authorized to change. Furthermore, the data being placed in the record is edited to ensure that it matches the data element specification for the element addressed.
CONTROL AREA: PROGRAMMING TECHNIQUE
27. Ensure Work Space Integrity. The unused space in a data record and the unused space in a main storage allocation should be filled with a known pattern of bits. Some programs fill such spaces with a supervisor call to an error routine. Checking the pattern can determine whether the unused space is in fact unused and stays that way.
28. Use Space Erase. After each input transaction has been processed, some large systems obliterate residual data to prevent previous values from being accidentally used in subsequent processing. The pattern used to obliterate data should not be a legal combination of characters (i.e., blanks, zeros, nines) because a program that fails to initialize its work space could still run properly under some circumstances. This is one of a set of techniques designed to keep a program within its allocated data and instruction space and to ensure that the program controls its entire environment but uses only data that it controls.
One efficient way to set unused space to null values is to obtain the actual length of the record just read and store null values in any allocated but unused space set aside for the record. The original record length should continue to describe the length of the occupied space, unless it is consciously adjusted by a program adding a field, deleting a field, or extending an existing field. After all processing is complete, the updated record length can be used for two purposes: to write the modified record, and to check that any residual unused space is still filled by the null values stored after the read but before the processing sequence.
CONTROL AREA: EDITING
29. Establish Classes in Edit Specification. Many financial systems have established credit classifications and adjust a credit rating dynamically based on the customer’s basic rating and the current status of the account. After the adjusted rating is established, the editing system invokes dollar limits appropriate to the customer’s adjusted rating.
Similarly, inventory systems establish classes for customers and edit order quantities for reasonableness against those customer classes.
For example, a utility might establish four classes of subscriber service: apartment, single-family residence, large residence or light industry, and heavy industry. As meter readings are processed, edit criteria appropriate to the service classification would be invoked. Erroneous readings, overdue bills, or unusual use would all be recognized because use and edit criteria would be related according to the gradations established by the classification system.
30. Provide Classes of Limits. Many database systems keep an order quantity limit on the master file along with the product description and status. If a quantity requested exceeds this limit, manual confirmation of the order is requested. In more sophisticated systems, a series of limits are stored by customer class so a small customer is protected against overordering by a low limit.
31. Define Normal Limits. When many independent transactions are received related to members of a homogeneous group (e.g., customers, individuals, parts, or accounts), an aggregate average across all members of the group allows the system to determine whether any individual member of the group deviates significantly from the average. In addition, if the group average deviates unpredictably from its previous average for this same group, the entire batch of transactions can be held until the deviation is explained.
32. Set Trend Limits. The behavior of an individual input transaction can be compared with the aggregate behavior of all individuals within its population or with its own previous behavior. The latter requires that a behavior history be maintained for each account so that account activity is retained for future comparison.
33. Establish Error Suspense Files. When input transactions are lengthy and error corrections usually affect only a small portion of the original record, suspense files containing original records (complete with errors) are frequently maintained. The correction process then consists of reentering identifying information plus the fields in error. The computer updates the queue of incorrect transactions, usually by simple field replacement, and then passes the modified transaction back to the main input editing module. It is important that the entire corrected transaction be passed through all of the editing procedures and that it is not assumed that what was valid before is still valid.
When systems are designed to maintain queues of transactions pending correction, an effective way to uniquely identify the error to be corrected is to cause the erroneous data to be reentered along with the transaction ID and the replacement data.
34. Maintain Limits. Several editing schemes require data stored on a file to establish the editing limits and to adjust them based on seasonal, -6me, activity, or cyclic factors. These systems require edit, update, and reporting modules to maintain the file of edit limits. Furthermore, such systems require special data or additional programming to initialize the system at start-up before any real history is available.
CONTROL AREA: POSTPROCESSING VERIFICATION
35. Use Dummy Processing. A frequently used practice places dummy master records on the file and routinely processes fictional transactions against those dummy master records to produce predictable output. The results of processing are forwarded to the control group, which routinely confirms that the item counts for all input items were processed and verifies the control totals for those items. The results from the processing of fictional data against the dummy accounts are also verified to ensure that the actual detailed processing was correctly performed. In the case of a payables run, the check written for the dummy account must be captured and destroyed.
This technique works on many types of files. For example, a record can be established for a dummy part number in an inventory file, and fictitious receipt and withdrawal transactions can be processed against that part number. If the inventory algorithm embedded in the processing program is understood, input data can be prepared to test limit checks and a variety of transaction processes. The resulting inventory on hand is predictable and the processing procedures can be checked by verifying the computer-produced results against the predicted values. Sets of dummy records and dummy transactions can exercise a computer program and provide confidence that typical transactions are being processed correctly.
CONTROL AREA: TROUBLE SYMPTOMS
36. Analyze Exception Reports. A computer system can be designed to reject obvious mistakes and to process suspicious transactions while listing their occurrence on an exception report for manual review. The very quantity of items requiring review is an excellent indicator of the general condition of the system. In addition, the exception reports provide an indication of whether the trouble is consistent or, in the absence of a pattern, merely related to individual transactions. Examples of what exception reports might cover are: high-priced items only; all subscribers residing in California; items manufactured by the XYZ Co.; or only items input on December 15.
37. Monitor Performance Changes. Performance changes are an indication of general systems condition, provided the programs have not been modified since the previous run. The operations staff should be notified whenever a program is changed. Furthermore, the operations staff should be provided with an indication of the processing pattern so that staff members can sense performance changes during lengthy runs. For example, the staff can be provided with an audio amplifier for CPU activity, a CPU activity meter, a hardware measurement box, or a printout of the CPU time used per transaction.
38. Inform Operator of Performance Anomalies. In some cases, the estimated run time can be predicted by an equation based on a simple count of the input transactions. In other cases, run time must be estimated by a more complex equation that operates on the number of transactions in each of several transaction classes. In still other cases, the transaction run time varies unpredictably based on the parameters in the transaction and the constitution of the values contained in the files. Commands that select records from a database can cause varying parts of the entire database to be read in response to an inquiry. In these cases, operators should be provided with in-process progress reports (percentage of the transactions processed or percentage of the database read) so that they can confirm that an unpredictable process is progressing satisfactorily.
The purpose of informing the operators of unpredictable transactions that are being processed is to confirm, by implication, that the remainder of the processes are predictable and that therefore performance should conform to historical expectations.
A large file system should provide a communications path from the computer operator back to the system manager so that unexpected activities can be reported for review.
39. Analyze Adjustments. The system can be programmed to recognize unusual transactions. For example, utility companies traditionally keep historical records of customer use, adjust them for seasonal and temperature variations, and use this data to screen each customer’s current use for reasonableness. After all the out-of-character transactions are posted to an exception list, they must be manually reviewed to determine whether or not they are errors. The volume, magnitude, and sense of required adjustments provide an indication of problems in the flow of data through the system. Adjustment analysis can pinpoint the areas that need to be reviewed for correctness.
40. Analyze Error Logs. All errors should be logged. In addition to recording the error and storing a unique error code, an error log should contain enough information to identify the discrete data path from the originator to the computer (e.g., source, observer, keyboard operator, batch, dates). The error log must contain the information necessary to identify the input transaction in its own local processing sequence. It should present the customer classification awarded by the input screening process, any classification associated with the master file, and the type of error discovered.
The log should aggregate statistics on error trends during that processing run, day, week, and month; the entire context must be logged with the error.
Careful analysis of such an error log can pinpoint error-prone processes or deficiencies in the system design that can be improved for economy and efficiency. Systematic improvements usually yield additional benefits in personnel efficiency: a high volume of routine errors often causes personnel to assume that errors are to be expected and to be less cautious in their own activities. When corrections that dramatically decrease the number of errors are made, personnel become more careful.
CONTROL AREA: OPTIONAL CHECKING
41. Establish Adaptive Checking. Computer operators learn the processing rhythm of a large job even when multiprocessing. Some systems have been constructed with optional checking features that can be invoked either by internal checks or by operator action. One system had a series of expensive checks designed to guarantee the continuing integrity of the database; they were inhibited during regular operations but invoked whenever the operator desired confidence that a suspicious processing pattern was not destroying the integrity of the database.
42. Ensure Program Integrity. Some program designers structure their object program modules into read-only (reentrant) areas and into read-write (serially reusable) areas. A simple checksum on the read-only areas provides an initial value; subsequent checks at break points in the process can ensure that the program and its tables remain as loaded and unmodified.
More sophisticated checks are required to verify the patterns in the read-write areas. If these are performed at major break points in the process, the parameters and most work space use can be verified, proving the program is performing correctly to the extent that the output areas are properly configured and formatted.
43. Provide Automatic Error Analysis. One leading manufacturer enhanced its operating system software to provide increased availability. It determined that system crashes were accompanied by incorrect modifications to the control blocks or parameter strings that dynamically controlled the operating system. To minimize the effects of an error and allow the system to be restarted with the greatest portion of the work load surviving, a series of optional programs called checker/fixers were provided. When called during the restart process, each checker verifies the format and contents of a control block. If the block is incorrect, the checker optionally calls the fixer to rebuild the control block from other available information stored redundantly within the system.
Many commercial applications operate on several separate strings of data simultaneously and can benefit from an adaptation of the same technique. The extent of the error must first be determined and operations restored as soon as possible for the healthy parts of the system. Massive system restarts provide opportunity for compound failures: restarts frequently violate system controls and usually cause all operational personnel to follow unfamiliar and sometimes untested procedures.
44. Verify Duplication. Every database has some built-in redundancy; in a well-designed database, redundancy may be considerable. A separate audit program can be created to check redundancy and verify the integrity of the file set. If properly programmed, some sections of the audit routine can be embedded in a file duplicate program so that the process of creating a backup file also checks that file for correctness.
A simple utility program copies records from one file to another, treating each record only as a string of bits. A more sophisticated utility program first obtains the file description from the database dictionary. As each record is copied, the program verifies the specification for data elements, detail records, summary records, and the file structure. Because 100 percent of the file is handled every time the file is duplicated, a merger of the audit program and the file duplicate utility produces a major benefit at a small extra cost. If the file is self-defining, the audit/duplicate program need not reference the database description. This procedure works equally well on current files and archival files, although the file definitions may have changed over time.
CONTROL AREA: MATHEMATICAL COMPUTATIONS
45. Identify Arithmetic Representations. Every computer treats certain arithmetic points in a unique way. Before performing extensive math on an unfamiliar computer, each programmer should discover the arithmetic singular points in the system to determine whether these idiosyncrasies will affect the planned calculations. For example, if a negative number is subtracted from its equal (e.g., -5 - [-51]), some machines yield a zero with negative sign. If this result is then presented as an argument to a subroutine that accepts only positive arguments, it will be rejected.
46. Check Finite Arithmetic. Arithmetic operations using the full range of a computer’s arithmetic registers emphasize the importance of round-off, truncation, and the residue following arithmetic manipulations. Although programmed double-precision operations may not be contemplated, each programmer should discover how arithmetical calculations are treated at the extremes of the numeric ranges and whether the residual values are reliable or not.
Because some systems behave differently when performing fixed-point, complement, and floating-point arithmetic, the results from each of these types of computation should be reviewed.
47. Beware of Numerical Hazards. Programmers should beware of the singular points that are created by performing arithmetic on nearly equal floating-point numbers in the middle of a complex expression, the possibility of floating-point underflow and overflow, and the risks of division by zero.
48. Calibrate Numerical Approximations. Many manufacturers offer subroutine libraries and, in some cases, built-in transcendental functions. Frequently, these are represented as primitive computer operations and treated routinely as an extension of the order list. Each user should calibrate the subroutine library to be used and enter the accuracy achieved by the algorithms it contains into the programming manual. Considerable effort is required to validate a library of subroutine approximations.
49. Perform Parallel Check Calculations. In many scientific calculations, two different sets of equations often produce the same result, or in some cases, an additional equation can be introduced that exploits another physical property and provides a check calculation. When such redundant calculations are performed, the correct operation of the system can be verified. As a byproduct, the accuracy of the computer solution can sometimes be estimated. For example, an energy balance equation can be integrated with the equations of motion for a missile. The continuity of mass in the energy equation guarantees that no gross errors have been made as the set of differential equations are integrated.
50. Detect Errors with Numerical Aggregates. In repetitive scientific calculations dealing with many observations of well-behaved data, standard statistical techniques (e.g., mean, variance, skewness, kurtosis) detect gross errors in the observations or subsequent processing. An example outside the field of science is the use of statistical measure to verify that stock market transactions were properly reported and processed.
CONTROL AREA: DEVELOPMENT METHODS
51. Pilot Test Input. When designing a larger high-volume system, the input system should be programmed first and pilot tested under actual or simulated conditions while the rest of the system is being completed. The results of these pilot tests should be used to verify the design, documentation, and planned training and, most important, to check the assumptions on which the input system design was based.
52. Manage Keyboarding Errors. In large shops with a high volume of similar keyboarding, error statistics should be kept by machine and by employee. Through the use of various employee-machine combinations, the error statistics can isolate employees with the best and worst records. These statistics should be analyzed so that the techniques of the superior employees can be shared and the habits of the inferior employees can be modified.
CONTROL AREA: SYSTEM TESTING
53. Create Data for Test. To provide a test environment without the risk of allowing an unchecked program to access real files, a set of test files should be maintained whose structure is identical to the structure in the live database. The operating system should select test or real files according to a control parameter that designates whether the run is test or production. Satisfactory runs on the test file should be mandatory before a modified system is allowed to run in production.
54. Build in Verification Tests. When many data cases are run through a complex calculation, a standard case should be run routinely before, during, and after the massive set of live data. This verifies that the program and the computer system were operating correctly (at least for the paths exercised by the standard case) throughout the production run.
90. Build in Exercisers. In an interactive system, a standard demonstration program should be cataloged and each remote terminal operator should be provided with a script that accesses standard data, exercises the system, and produces predictable results. The remote operator can then be assured of an operational terminal, communications network, central computer, operating system, and at least one operational path through the applications system and the DBMS. With experience, the remote operator can also determine whether the system response time is within normal limits.
56. Build in Diagnostics. In the event that a remote terminal operator invokes the standard exercise package and receives unexpected results, a separate input diagnostic package can be invoked so the operator can follow a predetermined input script and the input diagnostic package can determine whether the character strings received are exactly those expected.
Similarly, a file of predetermined output can be stored and an output diagnostic program can be invoked to display the output to the remote operator. The operator can then determine whether the standard output is being received and properly displayed or printed. The canned output stored for such a diagnostic program is usually geometric in nature. Patterns are displayed or printed to place known characters in the first and last display position of each and every line, cover the display field with a readily recognized pattern, and display every graphic character to ensure the character generation circuitry is properly functioning. All electromechanical functions of a printer are similarly exercised.
Given the results of the input and the output diagnostics, the remote operator can intelligently call for assistance and indicate what seems to be the problem.
57. Perform Communications Exercises. Communications lines that interconnect intelligent devices to computers and computers to intelligent multiplexers can be directed to repeatedly exchange standard messages to calibrate the line. If the measured error rates are excessive, the line can be scheduled for repair. In the interim, the line speed can be changed, alternative network paths can be used, or line capacity can be exchanged for optional checking.
58. Perform Online Testing. In any system that involves elaborate error checking, provision must be made for declaring entry into a test mode so that the fault detection logic can be exercised by introducing faults into the system. The purpose of the test mode is to inhibit the sounding of alarms, the printing of error messages, and the logging of test events as actual errors, thereby destroying the integrity of the error statistics.
CONTROL AREA: ORGANIZATION
59. Establish Database Administrator Position. Even if all the files are related to a single system of application programs and no third party uses the data being created, a database administration function can facilitate systems management. As systems get larger, database administration is often separated from development programming, maintenance, and production operation. This pares the jobs down to a reasonable size and concentrates a series of similar functions under one administrator.
The database administrator and staff should address:
• Definition • Data elements
• Controls • Formats
• Procedures • Records
• Backup • Files
• Transitions • File sets
In addition, the data base administrator should be solely responsible for the use of file utility programs to:
• Audit • Reconstruct
• Verify • Initialize
• Duplicate • Reorganize
60. Organize for Integrity. Organizational responsibilities need to be reviewed, programming standards need modification, and the work force needs discipline to ensure that changes to a production system are controlled and loss of data integrity is avoided.
Data stored and untouched in a perfect world does not deteriorate. Machines, operators, and programmers, however, make mistakes. These are not always detected; even when they are, the correction of mistakes sometimes introduces other errors. Data can therefore deteriorate over time even when no transactions that update specific individual records are processed against the master file. Changes must be controlled and files must be audited to maintain data integrity over long periods. To ensure this, the organizational responsibilities must be properly defined and the files properly designed.
61. Implement Quality Control. Most DP shops have a control group, a team through which all computer input and output must pass. The control group checks the control totals on input batches and reconciles totals on output reports against the most recent input and the current file statistics. Report control totals must be reviewed before reports of other computer-produced documents are distributed. In addition to checking 1/0 totals, the OA group uses statistics to check file integrity and histograms of the input transaction mix so that deviations from the norm are caught before erroneous information is distributed. (Unfortunately, this control group must work when the production is being run, and that usually implies second and weekend shifts).
62. Use Master File Verification. A properly designed database contains sufficient redundancy to ensure that its integrity can be independently verified without reference to other files, indexes, or supplementary information. An audit program is used to perform this verification. Typically, the file structure is explicit and additional redundant data elements are included that contain item counts, numerical sums, or hash totals. For more complex files, truth tables describing the logic and record sequencing are placed in a descriptive record at the beginning of the file. The database administrator should own the database audit program and run it for the benefit of all users sharing data. If running the program is expensive, samples of the files can be checked on consecutive runs. Runs can also be triggered by certain performance problems.
The database administrator and the data librarian must coordinate their efforts to ensure that the release of grandparent files depends on both age and proven data integrity. Whenever a 100 percent sample of any file within a file set is checked, the audit program should verify all file controls and totals. Any errors should be resolved by the control group so that the baseline totals for the next set of production runs are automatically adjusted.
The relationship between audit activities and the file retention plan deserves further comment. When a computer center deals with a master file that is cyclically updated, a retention plan is usually established that defines how many consecutive obsolescent versions of the master file should be retained. In batch operations with weekly updates, the current file plus the master files of last week and two weeks ago (i.e., child, parent, and grandparent versions) are usually saved.
If the audit program is run every two weeks to verify the integrity of the master files, a retention plan providing for three cycles is sufficient. The file set, however, may be massive; the audit program may be long-running; or the audit program may be set up to perform a 100 percent verification of only a portion of the file. In these cases, the audit cycles must be considered when the retention plan is being prepared; it may be desirable to retain additional cycles of the obsolete master files to accommodate the audit cycle (i.e., the audit cycle and the retention plan cannot be independent of each other).
63. Build Local Expertise. User-oriented programming packages provide risks as well as advantages. These packages are often bought under the assumption that little or no programming is required for their installation and use. When these packages are used for the main production flow or to summarize important data needed for decision-making, however, they introduce some risks.
Users of these packages can be successful without having copies of the source programs, without knowing the details of the file layout, and without understanding the intricacies of restart and reload procedures. With luck, they never need expertise on the internals of the database package; however, power failures do occur in the middle of updates, computer circuits sometimes fail, and programs stored in a library can deteriorate or become incompatible with the operating system over time. These systems can fail at critical times, and although the vendor may assist in diagnosis, long-distance problem solving is difficult and the quality of service received when the package is new often deteriorates over time.
If a programming package is used for critical work that must be completed on schedule, the manager should build some level of local expertise as insurance that the skills to deal with an emergency exist. This does not mean that every installation needs a seasoned programmer who is thoroughly conversant with every package. Instead, each manager should assess the organization’s risks and develop the level of expertise necessary to hold those risks to a reasonable level.
CONTROL AREA: COMPUTER OPERATIONS
64. Use Pilot Production Batches. On large production runs, a small but representative sample of data should be routinely run as a pilot production. The control group can then check the output of this pilot run as the main run is processing. (Sometimes this technique requires minor changes to the system design to be feasible.)
65. Ensure Integrity in Names. Check digits on procedure, job, and program names can be used to prevent calls for incorrect procedures or jobs. Although such incorrect requests are likely to abort, some may partially execute; they can destroy a portion of any database designated for output before the error is recognized.
66. Establish Online Controls. Although many information systems accept input in random sequence and process the input stream in an as-required order, some installations have found that controls, restart, and error resolution are greatly simplified if the input transactions are sorted onto ascending sequence on the primary file key before the main update run is scheduled.
Many systems are running with online update from remote terminals because an adequate system of controls has been satisfactorily automated. In some large and very complicated systems, however, online controls at the transaction level have proved difficult to achieve, and these systems must batch online transactions, sort them into a sequence, and supply a more traditional form of batch control procedure before the transactions are allowed to update the file.
67. Use Remote Backup. If continuing operation from an online system is absolutely necessary, and if two separate remote systems are justified, a duplicate file set and duplicate control tables should be maintained on both systems so that the basic data and the network context are available whenever the terminals are switched from the primary to the backup system. Some systems also require the log file with its before and after images to be maintained dynamically at both sites.


Previous Table of Contents Next