DOWHILE: Trailer Record Logic

Name: DOWHILE: Trailer Record Logic
Uploaded: 2017-07-19T20:57:07+00:00
Duration: PTM23S6
Channel: Merry Ball
Description: DOWHILE: Trailer Record Logic

DOWHILE: Trailer Record Logic
Programming Logic and Methods

Objectives Distinguish between header record logic and trailer record logic. Design programs using trailer record logic. Design programs that require heading, detail, and total lines. Design the logic needed to handle invalid input data.

Objectives (Continued)
Define and distinguish between the priming read and the loop read. Design the logic required for automatic end-of-file processing. Design a program that outputs headings on every page of a report.

Trailer Record Logic With header record logic we used the first input record to determine how many times to execute the loop. Now let’s look at using the last record input (trailer record) to control the loop. In this case, something about the last record indicates to the computer that no more records are to be processed. How do we distinguish or identify this last record? What is so different about it? (Answer: it depends …)

Trailer Record Processing
The key is that there is a value in the last record (called a sentinel or dummy value) for a chosen field that is not possible for any record in the input data. For example, an employee number of zero might serve as a sentinel value. Even though the sentinel value is what we are looking for, the last record may have to contain valid data for other fields anyway. Finally, trailer record logic does not require a counter for loop control ...

Sample Problem 6.1 (p. 102) Flowchart is on page 103 and following slide (no modules). Something new is introduced here too! START WRITE HEADING(S) etc.

Figure 6-2 Defective Parts (Flowchart)
Copyright ©2001 by Prentice-Hall, Inc. Upper Saddle River, New Jersey All rights reserved. Marilyn Bohl and Maria Rynn Tools for Structured Design, Fifth Edition

Pseudocode for Problem 6.1
Start WRITE Heading(s) COUNT1 = 0 COUNT2 = 0 READ CODE, PART, TYPE, DATE DOWHILE CODE <> 9 IF CODE = 1 THEN COUNT1 = COUNT1 + 1 ELSE IF CODE = 2 THEN COUNT2 = COUNT2 + 1 ELSE WRITE ‘Bad Input - wrong code!’ ENDIF WRITE CODE, PART, TYPE, DATE READ CODE, PART, TYPE, DATE ENDDO WRITE COUNT1, COUNT2 Stop

Heading Lines Serve as title for output report.
May contain column headings as well. Not necessary to know all about them in early stages of program development. Useful to indicate their presence when program logic is designed.

Detail & Total Lines Most of the report or printed output is made up of detail lines. In this example, the WRITE statement within the DOWHILE loop prints one detail line each time the loop is executed. Also in this example, COUNT1 and COUNT2 are used to keep track of the number of defective parts made by each plant. They are not used to control the loop but their values are printed at the end of the report. They represent the total number of parts returned for each plant. The line containing their values (printed at the end of the report) is a total line.

Priming Read and Loop Read
The first READ in this program (occurs before the loop) is called a prime read because it gets the computer ready to process the coming input information - I.e., it “primes” the computer. The other READ in this program occurs within the loop (and will usually be the last statement in the loop) - it reads the next available input record each time the loop is executed.

Sample Problem 6.2 (p. 106) This is problem 6.1 in modular form. We’ve added an IF statement to check for no input data (first record has a plant code of 9). Note from the structure chart on p. 107 that we have four second-level modules in this program. (I told you not to rely too much on generics!)

Figure 6-4 Defective Parts Problem (Structure Chart)

Figure 6-5 Defective Parts Problem—Overall Control (Flowchart

Figure 6-6 Defective Parts Problem (Pseudocode)
Start PROCESS Headings (B000) PROCESS Initialization (B010) Read CODE, PART, TYPE, DATE IF CODE = 9 THEN WRITE ‘No Data’ ELSE DOWHILE CODE ≠ 9 PROCESS Detail Record (B020) ENDDO PROCESS Totals (B020) ENDIF Stop Copyright ©2001 by Prentice-Hall, Inc. Upper Saddle River, New Jersey All rights reserved. Marilyn Bohl and Maria Rynn Tools for Structured Design, Fifth Edition

Figure 6-7 Defective Parts Problem—Process Headings

Figure 6-8 Defective Parts Problem—Process Initialization

Figure 6-9 Defective Parts Problem—Process Totals

Figure 6-10 Defective Parts Problem—Process Detail Record (Flowchart)

Figure 6-11 Defective Parts Problem—Process Detail Record (Pseudocode)
Enter IF CODE = 1 THEN COUNT1 = COUNT1 + 1 ELSE IF CODE = 2 THEN COUNT2 = COUNT2 + 1 Write ‘Bad Input’ ENDIF Write CODE, PART, TYPE, DATE Return Copyright ©2001 by Prentice-Hall, Inc. Upper Saddle River, New Jersey All rights reserved. Marilyn Bohl and Maria Rynn Tools for Structured Design, Fifth Edition

Automatic End-of-File Processing
A trailer record is not always necessary – most programming languages include a built-in function for detecting when the end of the input file has been reached. Instead of testing for a trailer value, we can modify the overall control module to test for the end of the input file after a read. While programming languages vary in how they do this, it is sufficient for now to include it in our logic design. This is called automatic end-of-file processing.

Automatic End-of-File Processing (2)
The overall control module (see page 111) has a slight change to handle the automatic end-of-file processing required in this case. The change occurs in the DOWHILE loop processing, as shown here: Start … DOWHILE not EOF ENDDO

Figure 6-12 Automatic End of File (Flowchart)

Figure 6-13 Automatic End of File (Pseudocode)
Start Process headings (B000) Process initialization (B010) Read a record IF end of file (EOF) THEN Write ‘No data’ ELSE DOWHILE not end of file (not EOF) Process a detail record (B020) ENDDO Process totals (B030) ENDIF Stop Copyright ©2001 by Prentice-Hall, Inc. Upper Saddle River, New Jersey All rights reserved. Marilyn Bohl and Maria Rynn Tools for Structured Design, Fifth Edition

Sample Problem 6.3 (p. 111) In keeping with the tradition of adding something a little new each time around, we added multiple headings this time! (We’re still working on the defective parts problem from before. This time we want to print the heading(s) on every page of the report.) Some other new twists in this example (see page 111 for details): page numbers on every page, and now automatic end-of-file processing - so we need to look at what those things involve.

Problem 6.3 (Continued) In order to know when to print headings, we need to know when the top of the page (or bottom of the previous page) is reached. If we know how many lines fit on a page (or how many we want to fit on a page) we can count the number of lines printed and then print headings each time we reach a page worth of lines. For example, if we want 60 detail lines on a page, we can count them until we reach 60, print headings again, and start the line counter over again. If we’re including page numbers, we simply increment the page number every time we print headings.

Multiple Headings (Continued)
See page 112 for the structure chart. New counters in this example are PAGECNT (initially set to 1) and LINECNT (initially set to 55 - why?) The headings routine is a C-level (third-level) routine this time - printing of headings is controlled by detail record processing, not by the overall control module as it was before (when we printed headings only on the first page). See the flowchart and pseudocode on page 113.

Figure 6-14 Defective Parts Problem (Structure Chart—Three Levels)

Figure 6-19 Defective Parts Problem—Multiple Headings—Process Detail Record (Flowchart)

Write CODE, PART, TYPE, DATE Return
Figure 6-20 Defective Parts Problem—Multiple Headings—Process Detail Record (Pseudocode) B010 Enter IF LINECNT ≥ 55 THEN PROCESS HEADINGS (C000) (ELSE) ENDIF IF CODE = 1 THEN COUNT1 = COUNT 1 + 1 ELSE IF CODE = 2 THEN COUNT2 = COUNT 2 + 1 Write ‘Bad Input’ LINECNT = LINECNT + 1 Write CODE, PART, TYPE, DATE Return Copyright ©2001 by Prentice-Hall, Inc. Upper Saddle River, New Jersey All rights reserved. Marilyn Bohl and Maria Rynn Tools for Structured Design, Fifth Edition

Multiple Headings - Summary
Two additional counters are needed when keeping track of how many lines have been printed on the current page (LINECNT) and how many pages have been printed so far (PAGECNT). These counters are initialized, incremented, and tested much the same way in any program that outputs multiple headings and page numbers. The partial flowcharts on page 117 show the basic steps required for processing multiple headings.

Multiple Headings – Summary
The use of named constants (such as MAXLINES) – variables whose value does not change during processing – to represent values makes for easier program logic. If we want to change the maximum number of lines on a page we simply modify the value of MAXLINES in our program. This is good programming practice! (Use named constants for all but the most trivial constants – such as zero and one - in your program.) Would you rather change MAXLINES – or try to find all occurrences of 55 and change them?

Credits Problem (6.4) This time we do not print detail records for every input record, but only for those students who have earned at least 60 credits. We use a trailer record that contains a negative number of credits. There are no totals printed by this program. Solution starts on page 118.

Summary: Four Approaches to Loop Control
Counter-controlled loop Header record processing Trailer record processing Automatic end-of-file These approaches are summarized in the flowcharts and pseudocode on pages 122 and 123.

Examples in Basic and Visual Basic
Enrichment Examples in Basic and Visual Basic

The CASE Control Structure
Chapter 7 Programming Logic and Methods

Objectives Upon completing this section you should be able to:
Distinguish between a master file and a transaction file. Identify, and use in program design, the CASE control structure. Distinguish between numeric and alphabetic data.

Introduction Businesses keep relatively permanent information for reference purposes. Consider a large university, for example: student information such as student name, ID number, address, and telephone number is stored in the student record. This information is kept for business purposes of the university. For instance, to mail schedules and bills, grade reports, or other information the university needs to know where to send it. This kind of file, containing reference or “permanent” information, is called a master file.

Master File Changes Just because information is stored in a master file does not mean it never changes. University students move. On completing a degree program a student might not take classes anymore, but the university wants to maintain records for information sent to its alumni. Changes to a master file are usually accomplished by means of a second file called a transaction file. Records in the transaction file might include changes to fields in the master file record, or may represent additions to the master file or deletions from it.

Inventory Control Example
The inventory control file contains information on the parts used during the manufacturing process. Each record contains a part number, description, quantity in stock, quantity on order, and perhaps other fields as well. Each transaction contains a transaction code that indicates the type of activity: 1 - Receipts (parts received as a result of orders) 2 - Orders (requests for more of this part) 3 - Withdrawals (parts taken from stock) 4 - Adjustments (other changes to inventory)

Inventory Control Example (Continued)
There are basically two kinds of systems like this: in one method of processing, all the transactions are entered and processed as they occur - typically at a computer or computer terminal, or using another input device like a hand-held scanner. (In a real-life situation this might mean that parts have a bar-code label which is scanned when the part is taken from inventory.) In other systems, transactions are collected and processed as a group (at the end of the day or overnight) - this is called “batch” processing.

Solution 1: Nested IF … IF CODE = 1 THEN Process receipt routine
ELSE IF CODE = 2 THEN Process order routine ELSE IF CODE = 3 THEN Process withdrawal routine ELSE IF CODE = 4 THEN Process adjustment routine ELSE Process exception routine ENDIF

Solution 2: CASE Structure
CODE = ? PROCESS RECEIPT ROUTINE 1 PROCESS ORDER ROUTINE 2 PROCESS WITH- DRAWAL ROUTINE 3 PROCESS ADJUST- MENT ROUTINE 4 PROCESS EXCEPTION ROUTINE OTHER

CASE Structure Pseudocode
CASENTRY CODE CASE 1 Process receipt routine CASE 2 Process order routine CASE 3 Process withdrawal routine CASE 4 Process adjustment routine CASE other Process exception routine ENDCASE

Sample Problem 7.1 Accept three values as input: first is an op code: A (add), S (subtract), M (multiply), or D (divide). Next two are numbers. Program will do the specified operation on the two numbers. For example, if the input is: S, 99, 32 the program will subtract 32 from 99 and print the result (in this case, 67).

Take a few minutes and try this yourself - without the book!
Your Turn! Take a few minutes and try this yourself - without the book!

(continued on next slide)
How Did You Do? Start READ OPCODE, NUM1, NUM2 CASENTRY OPCODE CASE ‘A’ ANSWER = NUM1 + NUM2 CASE ‘S’ ANSWER = NUM1 - NUM2 CASE ‘M’ ANSWER = NUM1 * NUM2 CASE ‘D’ ANSWER = NUM1 / NUM2 (continued on next slide)

Possible Solution (Continued)
CASE other ANSWER = 0 WRITE ‘Invalid Op Code’ ENDCASE WRITE NUM1, NUM2, OPCODE, ANSWER Stop

Sales Problem (7.2) Let’s revisit the sales problem we had before when we used nested IF statements, and use the CASE structure this time. The CASE structure makes solving this problem a little more straightforward and eliminates the need for nested IFTHENELSE structures. See the flowchart on page 135 or pseudocode on page 136 (and on the following slide).

Pseudocode Solution (Using modules)
Start READ NAME, NUM, SALES, CLASS CASENTRY CLASS CASE 1 Process Class 1 CASE 2 Process Class 2 CASE 3 Process Class3 CASE 4 Process Class4 CASE other Process Invalid class ENDCASE COM = SALES * RATE WRITE NAME, NUM, COM Stop

Process Class 1 B000 Start IF SALES <= 1000 THEN RATE = .06 ELSE
ENDIF Return

Sample Problem 7.4 Redo the previous example but at the end of the report print total lines showing the total number of each type of record, including invalid ones. Structure chart is shown on page 148.

Changes for Counters We are counting five different classes (all invalid codes count as one “class”) so we have five counters to initialize at the start of the program, and five to print at the end. We also have to remember to add a line to each Process Class module to count one more occurrence of this class. Take a look at the flowchart/pseudocode for each routine and compare it to the previous example to see what changed.

Homework Assignment Exercise 12, Chapter 7

DOWHILE: Trailer Record Logic

Similar presentations

Presentation on theme: "DOWHILE: Trailer Record Logic"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

DOWHILE: Trailer Record Logic

Similar presentations

Presentation on theme: "DOWHILE: Trailer Record Logic"— Presentation transcript:

Similar presentations

About project

Feedback