Speaker Notes to Accompany editscreen (Edit data input at a screen):

Slide #1:

This is a basic edit program using screen input. Records that have no detected errors are written to a good record disk file. Each error that is found is written to a report. If a record has any errors, it is not written to the good record disk file.

At the end of this presentation, I have included the logic flowchart. Clearly the logic flowchart should be done before the program is written.

Slide #2:

There are two output files: INVENT-FILE which is where records with no errors will be written, ERROR-REPORT which is where each record is written out individually.

Slide #3:

This construction lets me move a alphanumeric field of up to 20 characters to DATA-PROBLEM-PR. It also lets me move a numeric field with up to five whole numbers and up to two decimal numbers to NUM-PROB-PR.

Slide #4:

I have used level 88 to define condition names for many fields.

Note that the sum of the data defined under DATA-FROM-SCREEN is 46 characters which is the length I gave the record that will be written to the good record file.

1 + 3 + 20 + 2 + 5 + 5 + 5 + 5 = 46

Slide #5:

Remember, if a field is broken down, there is no picture on the original level. COBOL will sum the parts and determine the length of the original field - in this case ITEM-IN-WS which is determined to be 4 characters (1 + 3).

Slide #6:

This slide shows the things needed to handle headers. It also shows the layout of the total line.

Slide #7:

The SCREEN SECTION is a new section in the DATA DIVISION that is used to lay out the entire screen. Not all COBOL's use the same process for defining whole screens.

The screen section allows me to layout the whole screen as opposed to the traditional DISPLAY/ACCEPT which deal with one line at a time. In this program I used the code for the colors instead of using the defined names.

The TO takes in data that is keyed on the screen and moves the data to the name given in the TO phrase. In this program, these names are defined in WORKING-STORAGE.

Slide #8:

This is the layout produced by the screen layout on the previous slide. Notice that in some cases there are multiple things on the same line and that the choices are given column numbers that put them in the middle of the form.

Slide #9:

Note that the original DISPLAY/ACCEPT combination is like the initializing READ. They get the full screen of data for the first record that is input by the user. All other data will be collected by the DISPLAY/ACCEPT combination at the bottom of the B-200-LOOP.

Again, compare this to the structure used to READ a record from a file.

Note that processing stops when the user enters Q,

At that point, totals will be produced at the bottom of the error report.

Slide #10:

I might not want to count cancelled records as invalid. If that is true, then I would have to ask the parts of the IF statement separately and only add to the invalid counter if an error was found.

In fact, all records that are processed here will have the C since if a Q is entered, I stop processing. In other programs I might have other options here and so I decided to test for the C - it definitely was not needed.

Slide #11:

This slide shows the total routine where I move the accumulators to the total line and then write the total line.

It also shows the header routine.

Slide #12:

Remember the item number that the user keys in should have a letter in the first character and it should be one of four valid letters. The next three characters should be numeric.

Slide #13:

In this code I am checking the name, the department number, the number on hand and the number on order for specified errors. In each case if an error is found, I move the data that is wrong to the data problem field on the error report and an appropriate message to the error message field on the error report. Then I do the routine that completes the processing of the error.

Slide #14:

The validity of the cost is tied to the department code. There are three valid department codes and each one has different cost specifications.

This code checks to make sure the cost is in the valid range.

I use next sentence for ease of coding. If the cost is valid, I will move to the next sentence. If the cost is not valid, I will do the standard error processing.

Slide #15:

Before I check the price, I need to do some calculations to give me percents to check to determine if the price is valid. An invalid price is greater than 25% and below 10%.

Slide #16:

I used a utility routine (U) to handle a routine that is performed from many places in the program.

It should be notes that I-O, reading and writing are the most "expensive commands". By writing once rather than writing every time I find an error, I generate a more efficient program.

Slide #17:

The first part of the logic flowchart for this problem. The logic flowchart should be done before the program is written.

Slide #18:

Note that I do not always put the little details in the flowchart. For example in B-200-LOOP I did not use move spaces to inven-rec. This is not really part of the logic - it is a housekeeping detail.

Slide #19:

Continuing the logic flowchart: the routines that do the editing. Edit Record performs all of the other routines that check individual fields. In this module of the flowchart, we see the routine to check the id or item number and the item name. Note that checking the item number involves making sure there is a valid code in the first character and that the rest is numeric.

Slide #20:

More edit checking. This is checking dept, on hand and on order.

Slide #21:

This is checking for a valid cost associated with a valid department.

Slide #22:

End of the logic flowchart. This shows the last check for price, the terminate and the utility error report. Please be sure to note that when an error is found the utility is executed and the utility does the things common to an error routine. In this example it moves YES to ERROR-IND which means the record will not be written to the file containing the good record collection.