1 / 39

Structured COBOL Programming

Structured COBOL Programming. 10th edition. John Wiley & Sons, Inc . Nancy Stern Hofstra University Robert A. Stern Nassau Community College James P. Ley University of Wisconsin-Stout. PowerPoint Winifred J. Rex Presentation Bowling Green State University.

Leo
Download Presentation

Structured COBOL Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Structured COBOL Programming 10th edition John Wiley & Sons, Inc. Nancy Stern Hofstra University Robert A. Stern Nassau Community College James P. Ley University of Wisconsin-Stout PowerPoint Winifred J. Rex Presentation Bowling Green State University

  2. An Introduction to Structured Program Design in COBOL Please note that the original slides will be modified in a number of places by your professor. These changes are for pedagogical reasons. Chapter 1

  3. Chapter Objectives To familiarize you with • Why COBOL is a popular business-oriented language. • Programming practices and techniques • History of COBOL • Use of the current ANSI standard versions of COBOL • Four divisions of a COBOL program

  4. Chapter Contents • Computer Programming: An Overview • Applications Program Development Process • Nature of COBOL • History of COBOL and the ANS Versions • Techniques for Improving Program Design • Sample Programs • Entering and Running a COBOL Program on Your Computer

  5. Computer Program • A set of instructions that enables computer to process data • Also called software • Two types of computer programs • Operating system programs - control overall operations of computer • Oftentimes called System Software • Applications programs - perform tasks required by users • Often called Applications Software Us.

  6. Applications Programs • Written by applications programmer • May provide quick solution to one-time problem • Displaying average grade for set of exam scores • Or may be run on regularly scheduled basis • Program to print student transcripts each semester • Program to generate a Payroll • Program to generate and print an Inventory Listing

  7. Application Programs - Customized • Written for specific users like doctors, car dealerships • Necessary if user has special requirements

  8. Applications Package – General Usage • Written for general user who needs program to perform standard tasks • Standard tasks include budgeting, scheduling payroll, etc. • Cheaper, easier than writing customized program

  9. Program Languages Machine language • Only language computer understands • All programs executed on computer must be in machine language • Machine language programs difficult to write • Written in binary, such as: • 0001101001010100 (actual instruction) • 010110101000000011000100 (actual instruction in binary)

  10. Assembler Languages • Level ‘higher’ than Machine Language. • Use mnemonic codes rather than pure binary digits, such as: L R5,X AR R5,R4 ST R5,SUM • Each of these instructions translates (normally one-to-one) into a machine language statement (that is, binary…)

  11. Program Languages Symbolic language (like COBOL) • Called Higher-Level Languages • English-like languages used to write programs • Easier than writing programs in machine language or assembly languages. • Must be translated or compiled into machine language to run on computer

  12. Program Development Process • Determine Program Specifications – the “Whats” • Design Program Using Program Planning Tools – the “Hows.” • Code and Enter Program (using some editor) • Compile Program Implementation • Test Program • Document Program

  13. 1. Program Specifications • Systems analysts, users and programmers develop specifications • Specifications include: • Description of input and output data • Description of what the program must do to the input to convert it to the output - that is, WHAT the program is to do. • They may provide formulas, constraints on data, conditions, etc. etc. BUT (again, notHow the developers accomplish this!) • In a perfect world, Systems Analysts specify the ‘requirements’ needed. (doesn’t always work this way.)

  14. 1. Program Specifications Record layout forms describe format of input and output data • Data names of each data item in record • Location of each data item in record • Size of each data item • Number of decimal positions (for numeric data items) • Please note that exactly WHO does this may vary depending on the expertise of the systems analysts, developers, etc. But these are part of the Specifications.

  15. 1. Program Specifications Printer spacing charts describe • Spacing of outputs (see pp 6-7) • hard copy reports • screen layouts, etc. • Layout of printed output • Heading, detail, total lines • Error messages and locations…

  16. 2. Design the Program Program planning tools used to map out structure and logic of program Once specifications are captured (discuss!), design takes place. Two real kinds of design: • Architectural design (high level, parts; components, blocks of functionality; relationships among these blocks, and • Detail design – the logic inside each block, part, component, etc.

  17. 2. Design the Program • Different tools may be used to capture the preliminary (architectural) design as well as the detail (logic; algorithms) design. • Architectural Design: • For many traditional systems, we may use Data Flow Diagrams; Structure Charts, System Flow Charts, and similar technologies • For Detail design: • Most practitioners use flowcharts, pseudocode, HIPO, or other techniques to capture the module logic.

  18. Architectural design: Book suggests Hierarchy charts show relationships among sections of program. • We will use these and call them Structure Charts. • Book cites for Detail Design: • Flowcharts use block diagrams to represent logic – a graphical model, and • Pseudo-code uses English-like statements • This one is preferred but some hang on to the flowchart. In some cases, it ‘is’ clearer, though.

  19. 3. Code and Enter Program • Programmer writes and enters program into computer • Program written in symbolic language (like COBOL) • Called source program

  20. 4. Compile Source Program Compiler is program that • Checks source program for rule violations • Translates source program into object program • (See p. 8 for System Flow Chart. Know this.) Source program in symbolic language Translated by compiler Object program in machine language

  21. 5. Test Program • Test or debug program to ensure it contains no errors • Check for two types of errors • Compile-Time Errors • Execution Errors

  22. Compile-Time Errors • Errors detected by compiler during translation from COBOL to machine language • Detects violations of programming rules • Misspelled reserved words • Missing punctuation • Errors in use of the programming language • Also called syntax errors

  23. Execution Errors • Detected when program is run • Logic error causes incorrect output • Sequence of instructions incorrect • Wrong instruction coded • Run-time error if computer cannot execute instruction • Attempt to divide by zero • Attempt to read a file that cannot be found

  24. Debugging Techniques • Desk checking • always do this. Can be costly to omit. • Correcting syntax errors • Correct syntax errors and resubmit • Program walkthroughs • Sometimes done in teams; good approach • Can be done prior to submitting for compilation. • Executing the program •  Just because a program runs to EOJ, does NOT mean that program was successful!!

  25. 6. Document the Program • Documentation - formal set of procedures and instructions to specify how to use program • Written for • Those working with output • Computer operators who run program • Maintenance programmers who make modifications to program • In some circles called: program maintenance manual, operators manual, users manual, etc…

  26. Nature of COBOL • Business-oriented language • Great for business data processing • Large volumes of data • Great for data manipulation • No language is better for transaction processing or data manipulation than COBOL • Has other major deficiencies, but not these. • Standard language • English-like language • Multiply hours-worked by rate giving salary • Relatively easy to understand

  27. History of COBOL • Developed in 1959 as standard language to meet needs of business • Committee to develop language convened by Department of Defense • Included representatives from academia, business, computer manufacturers

  28. 1960s 1968 1974 1985 wide variations in COBOL compilers first COBOL standard set by American National Standards Institute (ANSI) second ANSI standard to make COBOL more efficient, standardized this ANSI standard incorporated structured programming techniques Standard Versions of COBOL

  29. Current and Future Standards •  1985 currently the most widely used • Sometimes called COBOL 2. • 2002+ is next standard • Approval expected in 2002 • Information on 2002+ COBOL standard at http://www.ansi.org

  30. Future of COBOL Likely to remain important language • Unlike academic environment, most programs are developed to be used for many years to realize a ROI. This implies the need to maintenance as requirements change and errors are discovered. • Older COBOL programs need to be updated • Still used by many for new program development

  31. Use of COBOL • About 200 billion lines of COBOL source code in use • 5 billion new lines added each year • Used by 42.7% of application programmers in medium to large U.S. companies • $200 million in expected revenues for 2001

  32. Year 2000 Problem (Y2K) • Year stored as two digits in older programs to save space • 19 assumed as valid prefix for all years • 95 represented year 1995 • Invalid as prefix for years 2000 and beyond • 00 could mean 1900 or 2000

  33. Year 2000 Problem (Y2K) Many calculations with dates incorrect starting in 2000 • To find your age if you were born in 1970 Subtract 70 from 95 (95 - 70 = 25) • Calculation incorrect for year 2000 and beyond 00 - 70 = -70 when age should be 30

  34. Year 2000 Problem (Y2K) To correct problem • Billions of lines of code, many written in COBOL needed to be examined • Code changed to use four digits for year • Age, other calculations now correct 1995 - 1970 = 25 2000 - 1970 = 30

  35. Improving Program Design Two techniques used to develop programs that are easier to understand, test, debug and modify • Structured Programming • Top-Down Programming

  36. Structured Programming • Eliminates use of GO TO statements • Allowed skipping to different sections of program without returning to starting point • Advocated the use of simple program constructs: • sequence • selection • iteration plus two extensions (later) • Program logic easier to follow with "GO-TO-less" programming

  37. Structured Programming Program divided into paragraphs • Main paragraph or modulecontrols logic flow using PERFORM statements • Sometime called a ‘driver’ module… • Main module "performs" other modules when instructions in that module required • Control transferred to a different paragraph and, upon completion of the instructions in that paragraph, control returns to the main paragraph. • Each module can be written and tested independently of others

  38. Top-Down Programming • Another technique to make programs easier to understand, test, debug and modify • Develop program like term paper • Develop outline first • Add details for each of main steps • Add further refinement for more complex steps

  39. Top-Down Programming For COBOL program • Code main modules or routines first • Code intermediate modules next • Details deferred to minor modules and coded last • We will use this technique a lot later on. We may refer to this technique as ‘drivers’ and ‘stubs.’ • This is an outstanding approach to developing larger programs…

More Related