Validation

Structured COBOL Programming,
Stern & Stern, 9th Edition

CHAPTER 11
Data Validation Techniques
OBJECTIVES
To familiarize you with:
1. The types of input errors that may
occur.
2. The techniques used to validate input
data.
3. The actions that can be taken when
input errors are detected.
Avoiding Logic Errors By
Validating Input
DEBUGGING TIPS FOR VALIDATING
INPUT
1. For every IF statement in a program, be sure
your test data includes multiple instances
when the condition is met and multiple
instances when the condition is not met.
2. If you use a line counter to determine when
a new page is to print, be sure you include
enough test data to print several pages.
DEBUGGING TIPS FOR VALIDATING
INPUT
3. If you have ON SIZE ERROR routines, be
sure your test data includes instances that
would produce size errors.
4. If logic errors occur that are difficult to find,
insert DISPLAY statements at various places
in your program during test runs to see what
intermediate results are being produced. Or
use the Interactive Debugger

DEBUGGING TIPS
Remember to eliminate these DISPLAY
statements after the program has been fully
debugged.
5. When producing disk output, always print a
copy of the resulting file and check it for
accuracy.
You can use a DISPLAY prior to the WRITE to
view the output on the screen, or you can use
an operating system command such as PRINT or
TYPE to obtain a printout of the file after the
program has been executed.
DEBUGGING TIPS
6. Pay particular attention to loop counts so
that a series of instructions is performed the
exact number of times that is required.
Often, looping is performed one time more or less
than desired. This can happen if counters are set
to 0 initially (when they should be set to 1) and if
the test for terminating the loop is not consistent
with the initial counter value.

Why Input to a Business System Must Be
Validated
Because input to a business system is often
voluminous, the risks of data entry or input errors
are great.
Steps must be taken to identify and correct these
errors so they are not processed by the computer.
Data Validation Techniques:
1. Routines that identify the various types of input errors
that may occur.
2. Error modules that print each specific error that has
occurred.
Some Consequences of Invalid
Input: Inaccurate Output
If a data entry operator enters a salary field
for a payroll record as 43265 instead of
41265, the result will be inaccurate output.
It would be extremely difficult for a program
itself to find such an error.
Some Consequences of Invalid Input: Logic
Errors Resulting from Erroneous Input
It is not unusual for programs that have
been tested, debugged, and run regularly on
a scheduled production basis to begin to
produce errors.
This situation will eventually arise if the
programmer has not anticipated every
conceivable type of input error.
Testing Fields to Ensure a Correct Format
The Class Test
Before actually processing
Program should first ensure that all input fields
have the correct format.
An input field has a PIC of 9's make certain that
the field does, in fact, have numeric data
What is the consequence?
Format for Class Test
IF identifier-1 IS {NUMERIC} {ALPHABETIC}
THEN* statement-1 . . .
[ELSE statement-2 . . .]
END-IF*
*Optional with COBOL 85.
The Sign Test
If a numeric field is to have either positive
or negative values
include a sign test to validate input data.

Format for Sign Test
IF identifier-1 IS {NEGATIVE} {POSITIVE}
{ZERO}
THEN* statement-1 . . .
[ELSE statement-2 . . .]
END-IF*
*Optional with COBOL 85.
Checking for Missing Data
One main source of error occurs when
input fields are missing data.
If key fields must contain data, they
should be checked before processing
continues:
IF SOC-SEC-NO = SPACES
PERFORM 900-ERR-RTN
Checking for Missing Data
Alternatively, we could use a class test
to determine if SOC-SEC-NO contains
non-numeric data:
IF SOC-SEC-NO IS NOT NUMERIC
PERFORM 900-ERR-RTN
The INSPECT Statement
Tallying and Replacing Specific Characters
with Other Characters to Minimize Errors
Applications of the INSPECT Statement:
1. To count the number of occurrences of a
given character in a field.
2. To replace specific occurrences of a given
character with another character.
The INSPECT STATEMENT
Format 1:
INSPECT identifier-1 TALLYING
{identifier-2 FOR {{ALL}
{LEADING} {CHARACTERS}}
{identifier-3} {literal-1}}
[{BEFORE} {AFTER} INITIAL
{identifier-4} {literal-2}]...
The INSPECT STATEMENT
Format 2:
INSPECT identifier-1 REPLACING
{{CHARACTERS}
{{ALL} {LEADING} {FIRST}}
{identifier-2} {literal-1}}
BY {identifier-3} {literal-2}
[{BEFORE} {AFTER}
INITIAL
{identifier-4} {literal-3}]}..

SELF-TEST
For the following statements, fill in the missing
columns:
FLDX
Statement Before/After Value of CTR1

3. INSPECT FLDX TALLYING 10050
CTR1 FOR ALL ZEROS
4. INSPECT FLDX REPLACING 10050
ALL ZEROS BY SPACES
CTR1 FOR LEADING ZEROS
CTR1 FOR CHARACTERS
BEFORE INITIAL '9'
Testing for Reasonableness
Range Tests
One way to validate data is to make certain that
fields pass a range test;
that is, the value contained in a particular field should
fall within pre-established guidelines.

Upper and Lower Bound

Limit Tests
When a field is not to exceed a given value we can
perform a limit test, which is simply a range test
without a lower bound.
Condition-Names: Checking Coded
Fields for Valid Contents
Coded fields are frequently used in input
records to minimize keystrokes for data entry
operators and to keep the input record
format shorter and therefore less prone to
errors.
Thus, a field used to indicate an individual's
marital status is not likely to be keyed as
SINGLE, MARRIED, DIVORCED.
Rather, MARITAL-STATUS might be a one-
position field that will be coded with a 1 to
denote single, 2 for married etc.
Condition-Names: Checking
Coded Fields for Valid Contents
To make the coded field more easily understood, we may
use instead 'M' for married, 'S' for single, and 'D' for
divorced.
Programs should make certain that the contents of coded
fields are valid.
Condition-names are frequently used to facilitate the coding
of error control procedures in a program.
05 Marital-Status Pic x.
88 Single value 1.
88 Married Value 2.
88 Divorced Value 3.
88 Valid-Martial-Status Value 1 2 3.
Sequence Checking
Frequently, input records are entered in
sequence by some control or key field.
A Social Security number may be a key
field for a payroll file, a customer
number may be a key field for an
accounts receivable file, and so on.
A key field may also be a control field if
it is used to signal a control break.
Sequence Checking
If the keyed input data is to be in
sequence, the actual order in which
records are entered should be
sequenced checked.
Sometimes records are to be in
ascending or descending sequence.
TYPICAL VALIDITY CHECKS
1. Determine if numeric data fields do, in
fact, contain numeric data. The class
test is as follows:
IF identifier IS NUMERIC . . .
2. Determine if alphabetic data fields do
contain alphabetic data. The class test
is as follows:
IF identifier IS ALPHABETIC . . .
3. Determine if data is missing. This can
be accomplished with the following test:
IF identifier IS EQUAL TO SPACES . .
.
4. Use the INSPECT statement to replace
all spaces with zeros in numeric fields.

After a field has been verified to see if it contains
the appropriate type of data you may need to
further validate data as follows:
5. Determine if the value of a field falls within an
established range;
this is called a range test.
6. Determine if the value in a field does not exceed
an established limit;
this is called a limit test.
7. Determine if specified fields contain
valid codes or values.
Use condition-names to help document
such routines.
8. Determine if input records are in
sequence, either ascending or
descending, based on the control or key
field.
Using the EVALUATE Verb for
Data Validation (COBOL 85)
The EVALUATE statement is commonly used
with COBOL 85 for data validation:
EVALUATE MODEL-CAR
WHEN 1 PERFORM 200-COUPE-RTN
WHEN 2 PERFORM 300-SEDAN-RTN
WHEN 3 PERFORM 400-CONVERTIBLE-RTN
WHEN OTHER PERFORM 800-ERROR-RTN
END-EVALUATE
The EVALUATE statement
The three most common formats are:

1. EVALUATE identifier
WHEN value(s) PERFORM . . .

2. EVALUATE TRUE
WHEN condition PERFORM ...
3. EVALUATE condition
WHEN TRUE PERFORM . . .
WHEN FALSE PERFORM . . .
TRUE and FALSE are COBOL reserved words that mean
`ìf the condition is met'' and `ìf the condition is not
met,'' respectively.
Other Methods for Validating Data: Use of Control
Listings for Manual Validation of Input
Computer errors commonly result from
erroneous input, but they can also result
from an intentional attempt to sabotage or
defraud a company.

One major method for minimizing the risk of
undetected errors is to print a control listing
or audit trail that includes:
Other Methods for Validating Data: Use of
Control Listings for Manual Validation of Input
1. the identifying data or key fields in each
input record
2. any errors encountered
3. totals of amounts accumulated for
groups of input records processed.
Other Methods for Validating Data:
Verification as a Means of Validating Input
Interactive Processing
One way to minimize keying errors when
input is entered interactively is to verify that
data has been keyed in properly using a
verification procedure.
After all data for a record has been keyed,
we can DISPLAY all the fields entered for
that record along with a message that says
'IS DATA CORRECT (Y/N)?'.

Other Methods for Validating Data: Verification as a
Means of Validating Input
We use the ACCEPT verb to input the
response.
If it is a 'Y' we continue,
If it is an 'N' we give the user an
opportunity to reenter the data.

Verification as a Means of
Validating Input
Another way to verify data is to have an
operator key each field in, transmit it to
the computer, and have the computer
`ècho'' that field back immediately to
verify that what was transmitted is
correct.
Verification as a Means of
Validating Input
A third way to minimize keying errors is
by using a rekeying or verification
procedure, which checks to see that the
data originally keyed is the same as the
data being keyed the second time.
If it is not, then the operator who is
verifying the data must find each error and
correct it.
WHAT TO DO IF INPUT
ERRORS OCCUR
WHAT TO DO IF INPUT
ERRORS OCCUR
Various types of procedures may be
employed when input errors are detected.
The analyst, programmer, software
developer, and user all work closely together
to establish the most productive course of
action to be taken.
We consider several procedures, any one of
which may be used in a program.
Print an Error Record Containing the Key Field, the Contents of
the Erroneous Field, and an Error Message
Errors should always be clearly displayed with
an appropriate message.
The key field that identifies each erroneous record
should also be included.
In addition, a count should be maintained of the
number of occurrences of each type of error.
Typically, the user would be responsible for
correcting all errors that have occurred.
Stop the Run
If a major error occurs, it may be best simply to stop the
run.
This procedure is followed when data integrity is the primary
consideration and errors must be kept to an absolute minimum.
Usually, a designated user would need to correct the error and
arrange for the job to be restarted.

If your program is to terminate because of an error,
remember to:
close all files before stopping, and
display or print a message explaining why the job is being stopped.
Partially Process or Bypass Erroneous
Records
Once an error is detected, the program could
either:
(1) proceed to the next record, bypassing the erroneous
record entirely
(2) process some portion of the erroneous record.

Sometimes, for example, an erroneously entered
numeric field is replaced with zeros in the output
area; sometimes the erroneous input is simply
ignored.
Stop the Run if the Number of Errors
Exceeds a Predetermined Limit
Often we wish to continue processing even if
errors occur, but if such errors become
excessive, we can stop the run.
Use Switches
Suppose we perform multiple validity tests on each record,
and, after all tests we wish to process valid records only.
That is, process records without any errors.

We may use a switch for this purpose.

We create a field called ERR- SWITCH initialized at 'N' for no errors.
If any error occurs, we move 'Y' to ERR-SWITCH in each error
routine to indicate that 'YES' an error has occurred.

After all validity tests, we test ERR-SWITCH. If it contains a 'Y', then
an error has occurred and we proceed accordingly. If ERR-SWITCH
is an 'N', then no error has occurred.
Print Totals
Print a Count of All Records and a Count of All
Errors
Programs should provide a count of records processed
as well as a count of errors that have occurred.

To determine the number of records processed, we ADD
1 TO WS-TOTAL-RECORDS each time we read a record
and print the contents of WS-TOTAL-RECORDS at the
end of the job.
Print Totals
Print a Batch Total
If large groups of input records are processed
we might include batch totals.
We would print a count of all records within specific
groups or batches of records.

Each individual total is called a batch total.
The manual batch totals should match the computer-
produced ones. If not, the user can track down the
record or records that were not processed in the
specific batch.
When Data Should Be
Validated
All programs to be run on a regularly
scheduled basis should include data
validation techniques designed to
minimize errors.
Understanding Program
Interrupts
During program testing, logic errors
sometimes occur that cause a program to
terminate.
Such a termination is called a program
interrupt.
Each time a program interrupt occurs, the
computer prints a brief message that
specifies the type of error that caused it.
COMMON PROGRAM
INTERRUPTS
DATA EXCEPTION
1. You may be performing an arithmetic operation
on a field that contains blanks or other
nonnumeric characters.
2. You may be attempting to use a numeric field
in a comparison and it contains blanks or other
nonnumeric characters.
3. You may have failed to initialize a subscript or
index or total field
COMMON PROGRAM INTERRUPTS
DIVIDE EXCEPTION
You may be attempting to divide by 0. (On some
systems, an attempt to divide by 0 will not cause an
interrupt but will produce unpredictable results.)
Can be caught by ON SIZE ERROR or a simple IF
ADDRESSING ERROR
1. You may have placed (or left) an incorrect value in a
subscript or index so that a table look-up exceeds the
number of entries in the table.
2. You may have coded nested PERFORMs (or GO TOs)
improperly. This error will also occur if there is an
improper exit from a paragraph being performed.
COMMON PROGRAM
INTERRUPTS
OPERATION ERROR
You may be attempting to access a file with a
READ or WRITE before opening it.

SPECIFICATION ERROR
You may be attempting to access either an
input area after an AT END condition or an
output area directly after a WRITE.
READ
READ file-name INTO data-name
AT END .
NOT AT END
END-READ

INITIALIZE
INITIALIZE group item-name

Comparing Dates
01 DATE-TODAY.
05 DATE-WS.
10 YEAR-WS PIC 9999.
10 MONTH-WS PIC 99.
10 DAY-WS PIC 99.
05 COMPLETE-DATE-TODAY-WS REDEFINES DATE-WS
PIC 9(8).
01 DATE-DATA.
05 DATE-DATA-WS.
10 YR-DATA PIC 9999.
10 MO-DATA PIC 99.
10 DAY-DATA PIC 99.
05 COMPLETE-DATE-DATA-WS REDEFINES DATE-DATA-WS
PIC 9(8).
01 DATE-LIMIT PIC 9(8).
International Considerations
Some Countries use commas to specify
decimal point
24,578.36 would be written
24.578,36

COBOL can recognize this by adding
Configuration Section.
Special-Names.
Decimal-Point is Comma.

Note. Configuration Section is part of
Environment Division.

Performance/Efficiency Tips
Usage is
Comp-3
Comp
Initialize
Move Corresponding
Corresponding

Questions?

Validation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Validation

Uploaded by

Copyright:

Available Formats

Structured COBOL Programming,

Stern & Stern, 9th Edition

You might also like