About Logic to Work in IT

By Roland Hughes

Logikal Solutions

The Minimum You Need to Know

Copyright 2007 by Roland Hughes

All rights reserved

ISBN 0-9770866-2-3

ISBN-13 978-0-9770866-2-7

This book was published by Logikal Solutions for the author. Neither Logikal

Solutions nor the author shall be held responsible for any damage, claim, or expense

incurred by a user of this book as a result of its use or reliance upon.

These trademarks belong to the following companies:

DEC Digital Equipment Corporation Hewlett-Packard Corporation

WordPerfect Correl Corporation

Depends Kimberly-Clark Worldwide, Inc.

PDP Hewlett-Packard Corporation

dBASE dataBased Intelligence, Inc.

Btrieve Pervasive Software

Novell Novell, Inc.

ISAM IBM (International Business Machines Corporation)

RMS Hewlett-Packard Corporation

VSAM IBM (International Business Machines Corporation)

CICS IBM (International Business Machines Corporation)

SyncSort SyncSort Incorporated

MQSeries IBM (International Business Machines Corporation)

MySQL MySQL AB

Unix The Open Group

Linux Linus Torvalds

ACMS Hewlett-Packard Corporation

PostgreSQL PostgreSQL Global Development Group

RDB Oracle Corporation

Oracle Oracle Corporation

All other trademarks inadvertently missing from this list are trademarks of their respective owners. A best

effort was made to appropriately capitalize all trademarks which were known at the time of this writing.

Neither the publisher nor the author can attest to the accuracy of this information. Use of a term in this

book should not be regarded as affecting the validity of any trademark or service mark.

Acknowledgments

I really would like to dedicate this book to the students about to embark on a career

in IT. Having spent nearly 20 years in this industry myself, I felt I owed it to the

following generations to put back some knowledge that has been lost in this industry.

It is an obligation of those who become seasoned in this industry to pass that

knowledge onto the following generations. This book is my attempt to pass some of the

most important, yet least taught, knowledge onto you, the reader.

Welcome to IT.

Source Code License

Unlike the other books in this series, there will be no source code for you to worry

about. While we will create diagrams and pseudocode, there will be nothing you can

actually compile and run.

Table of Contents

Introduction.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1

I.1 Why Logic?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-1

I.2 What is Logic?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-2

I.3 Prerequisites for This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-4

I.4 Approach of This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-5

I.5 Who Should Read This Book?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-6

I.6 Why is Flowcharting and Pseudocoding Shunned?. . . . . . . . . . . . . . . . . . . . I-6

I.7 Flowcharting and the Current State of IT. . . . . . . . . . . . . . . . . . . . . . . . . . . I-9

I.8 Additional Reading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I-11

Chapter 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Basics of Flowcharting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

1.1 Flowcharting Symbols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

1.2 Linear Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

1.3 Top Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

1.4 Middle Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11

1.5 Bottom Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13

1.6 Multiple Decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14

1.7 Flowcharting Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16

1.8 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17

Chapter 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Basics of Pseudocode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.1 What is Pseudocode?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.2 Rules of Pseudocode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.3 The Why and When of Pseudocode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

2.4 How Do You Learn to Write Pseudocode?. . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

2.5 Linear Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

2.6 Top Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

2.7 Middle Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

2.8 Bottom Checking Loop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

2.9 Multiple Decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

2.10 Pseudocode Followup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

2.11 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8

Chapter 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Some Fundamental Data Types.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

3.1 Core Data Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

3.2 Data Type Sizes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

3.3 Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5

3.4 Arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6

3.5 Records and Structures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7

3.6 Indexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

3.7 Record and Structure Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12

3.8 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15

3.9 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16

Chapter 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Searching and Sorting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.2 The Bubble Sort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.3 Class Exercise One. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

4.4 Linear Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

4.5 Insertion Sort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9

4.6 Class Exercise Two.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

4.7 Class Exercise Three. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

4.8 Shell Sort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13

4.9 Binary Search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14

4.10 Class Exercise Four. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15

4.11 Leaping Lynn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15

4.12 Class Exercise Five. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18

4.13 When All Search Routines Fail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19

4.14 The Two Part Compare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20

4.15 Comparing Dates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22

4.16 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24

4.17 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25

Chapter 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Decision Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

5.1 Choosing Your Decision Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

5.2 Creating an Extract File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

5.3 Class Exercise One. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5

5.4 Class Exercise Two.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7

5.5 Class Exercise Three. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8

5.6 Class Exercise Four. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9

5.7 Class Exercise Five. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10

5.8 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11

Chapter 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Knowing What Questions to Ask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

6.1 How are You Going to Use This?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

6.2 Who is the Audience?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

6.3 What Business Areas and Systems are Impacted by This?. . . . . . . . . . . . . 6-3

6.4 Is This Legal?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5

6.4.1 Example One. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5

6.4.2 Example Two (Where Did You Get This?). . . . . . . . . . . . . . . . . . . . . . . . . 6-6

6.5 Who Owns This Project?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8

6.6 How Will Success Be Measured?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9

6.7 Who Will Sign Off on This Project?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10

6.8 What are the Deliverables?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10

6.9 How Much Time Do I Have?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11

6.10 How Reliable Does This Have to Be?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11

6.11 What is the Required Availability?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13

6.12 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14

Chapter 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Linked Lists.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

7.1 Pointers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

7.2 A Singly Linked List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2

7.3 Doubly Linked Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

7.4 Which do you use?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7

7.5 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

7.6 Class Exercise One. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

7.7 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

Chapter 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Hash.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

8.1 What is a Hash?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

8.2 Collisions.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2

8.3 File vs. Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4

8.4 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5

8.5 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6

Chapter 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Relational Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

9.1 What is a Relational Database?.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

9.2 Some Important Relational Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2

9.3 Data Integrity and Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5

9.4 SQL and Flowcharting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-9

9.5 Summary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12

9.6 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13

Chapter 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Surviving the Fire.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

10.1 The Philosophy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

10.2 Beware the Deadly Embrace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3

10.3 The Stock Order Problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4

10.4 Some Career Advice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9

Introduction

I.1 Why Logic?

I could start playing the game with you and respond with Why not logic?, but it

is too soon in this book to tick you off; there will be time enough for that later. This

book came about for many reasons. It is not one I originally intended to write as part

of this short series, if ever. Many circumstances coalesced to allow time enough for it,

but there still had to be a need for this book to justify writing it. The need came from

a very odd place (at least for those of you unfamiliar with the ways of IT professionals):

conversations in bars.

Oh, this wasnt conversations with a bunch of grizzled coworkers swilling suds and

having a gripe session. These were conversations with college students when I actually

ran into one who was enrolled in some aspect of IT. My current consulting contract has

me staying near a college town, so when you head out for a beverage or eight, you

inevitably run into college students even in the old fogey bars. What was appalling

wasnt the fact that in a bar with more than 300 people you only ran into, at most, one

IT student, but what they were being taught. Logic isnt required any more at a lot of

campuses. Many others dont even offer it as a class.

In todays pointy-clicky world, logic has been tossed aside. The trouble with tossing

aside logic is that you toss aside what is the fundamental core of application and

system design. Once you understand that logic is no longer being taught, it is easy to

understand the complete lack of design so visible in todays PC and Unix products.

Those students who graduate today and actually accept a job working with a 3GL

writing non-GUI back end applications flounder miserably. Were there any justice in

the world, they would be able to get their money back from the university which gave

them the degree.

When I obtained my first degree some two decades ago, I saw the beginning of the

end for logic in college courses. They started teaching Pascal in the logic class. The

excuse was that students needed to implement the logic tools they were being taught.

The second excuse was that they needed to know Pascal to survive the data structures

class later in the curriculum. Neither argument was worthy of pushing any language

into the logic course. Being in the absolute last group of students to take the logic class

in its pure form, Im in a unique position to criticize the following classes. It also helps

to have gone back a decade later and heard much the same criticism from former

instructors. They claimed that none of the newer students did very well later in the

curriculum. That a lot of students changed their major when they started hitting the

more coding intense classes.

I-2 Introduction

The reason those students floundered isnt because IT got harder. Indeed, IT had

gotten easier by then with good 3GL compilers and syntax checkers. It was because

they had burned almost their entire logic class learning a 3GL (Pascal) rather than

learning the depths of logic. They were focusing on the syntax of a language. The

larger portions of logic, those portions that take you above simple program design into

complex application design and simple systems design, were never covered. When they

got to the more advanced programming classes, they had no frame of reference. They

did not know how to design a control break report, or even what a control break report

was. The last part is really sad considering how most college students have a credit

card. Every month they get a statement for their credit card account that is a control

break report.

Why logic? Because you cannot hope to succeed or even survive in software

development without it. Why logic? Because most of you have went through or are

going through a college curriculum that didnt teach you logic. Why logic? Because the

drive to be the absolute best in software development cannot be taught, but logic can,

and you cannot be the best without logic.

In years gone by, hiring a new programmer to your staff was much like buying a

new car. You got to pick and choose the features, but you never had to ask if the car

came with an engine. Programmers from the old curriculums all had been taught logic,

you didnt have to ask. In todays market, you have to ask if the car comes with an

engine.

I.2 What is Logic?

That is the fundamental question. There are many answers. Depending on the

situation surrounding the question, some answers are more correct than others. When

you complete this book and begin working in the real world of IT, you will constantly

use a variant of this question with every program and system you design. What is

logical?

No, Im not trying to lay a bunch of academic babble on you. People dont buy a

book they arent forced to read because they like having academic babble shoved down

their throats. I have found few things more boring than listening to what career

academics have said or reading what they have written. There are several periodicals

that handle that market. There was a time in my career when I believed I could obtain

something useful from them, so I paid expensive fees to read those magazines. What

I obtained from them was a substitute for Nytol most of the time.

Introduction I-3

Logic is the fundamental tool of IT. It is the tool from which all other tools are

created. There are many kinds of logic in the world of IT. Scholars would like you to

believe that there is only one definition of logic and it always yields the same outcome.

That statement is incorrect. They will try to proof their statements with truth tables

and lectures that glaze over your eyes inside of 15 minutes. Had there been even the

most remote grain of truth to those proofs AI (Artificial Intelligence) would have been

more than a mid-80s flash in the pan.

For logic to provide the same answer twice, given the same set of truths, you must

start in the same place each time. Logic isnt a set of gears producing the same output

every time you turn a crank handle. A single instance of a logic path will provide that

type of output. In the world of IT, we tend to refer to that single instance as a

program. When a program doesnt provide a consistent set of output, we say it has

bugs. The term bugs became shorthand for implementation failure. Every program

fails at some point. Because we dont like to say we exist to create failure, we say we

exist to create software and some of that software has bugs. It is probably a good thing

we call them bugs so the tool to remove them can be called a debugger, otherwise we

would be talking about running our programs through failure removal instead of

running them through the debugger.

Back in the beginning days of computers, they were a collection of tubes and

programmed by either wiring or tossing a series of switches. There was only one type

of logic: hardware. For most computers it was the hard-wired truth. A switch was

either on or off. Some computers, though few exist today, used frequency logic for

lack of a better term. They were analog, not digital. Most of you reading this should

be familiar with the classic sine wave from your math classes: the perfectly

symmetrical S laid on its side and a line drawn exactly through the middle of it.

Everything above the line was positive, or truth, while everything below the line was

negative, or false. Analog was much like real life. It allowed for varying degrees of

true and false. Some of you using digital cameras may have heard a term called fuzzy

logic. Fuzzy logic tends to get used in a lot of automatic focusing. (Those of you

reading this who are intimately familiar with analog computers and fuzzy logic, please

allow me some literary freedom here. Conceptually, they are similar as a car and truck

are similar. We dont want to go too far down a bunny hole at this point.)

There are still some analog computers around, thought not many. I dont

remember the exact problems they were the best at solving, but there is/was a niche

of software development which could use no other form of computer. I have a nagging

thought in the back of my mind that stellar drift calculations were among the

applications best served by analog boxes. If any of you reading this are old enough to

have owned the older cell phones, then you have a shining example of analog

technology. When you were in a bad spot you could still make out pieces of what the

other person said even with all of the static. With modern digital cell phones you

simply get a dropped call. Analog keeps going as long as there is any degree of truth;

binary stack dumps. Analog knew there was interference and allowed for it; binary

I-4 Introduction

requires perfection.

Logic has taken many turns during the past two decades. The study of AI and the

creation of truth tables lead to the creation of rules-based systems back in the mid- to-

late 80s. Truck loads of dollars were poured into companies claiming they would

create thinking machines and personal helpers with all of the intelligence of a hired

servant in just a few short years once the tables were constructed. There was a

market correction when none of these start-ups bore the tasty fruit investors were

looking to savor. Financially, it was not as horrific as the DOT COM flame out, and

it did not have quite as many criminals with their fingers in the venture capital grab

bag. It did have one very ugly side effect though logic got a bad wrap. Colleges

pretty much stopped teaching it and IT started a downward spiral.

Logic taken too far gives you problems like the AI investment debacle. What the

industry failed to realize is that logic, like cholesterol, must exist. There is good logic

and bad logic just like there is good and bad cholesterol.

The short answer is that logic is the most fundamental of IT tools. Logic is what

allows you to get from input to output, no matter what. Logic is the framework upon

which every computer application is developed, even the object-oriented applications.

I.3 Prerequisites for This Book

This book only requires that you have some interest in computers and software

development. It will help if you have poked around with some software development

tools or attempted some fundamental programming on your own. By fundamental

Im not talking about some GUI development product where you only clicked and

dragged things together. Im talking about older, lower level, C or BASIC programs

where you printed HELLO to the screen and tried to work out how to print columns

of asterisks from 10 down to one so they looked like a crude bar graph. If that last

problem sounds horribly simple, try doing it without having had a logic class. Try

doing it in under an hour. If you feel like adding insult to injury, try printing numbers

going down the left side, along with as solid a bar as you can print and letters going

across the bottom with a solid bar above them so it looks even more like a bar graph.

Dont worry if all you have is a casual interest in computers or software

development. We wont be writing any programs, only mapping out their logic, so you

do not even need a computer. You might want to surf the Web or visit an office supply

shop and see if you can find a flowcharting template. This is a little green plastic

thing with different shaped holes cut in it. You use it and a pencil to draw a flowchart

on paper.

Introduction I-5

I.4 Approach of This Book

Most books on programming logic tend to be less than 100 pages in length. The

reason for that is they focus on either flowcharting or pseudocoding, then stop. They

give you one or two problems that could relate to the real world, then leave you to

figure out things on your own. If Im going to slam those books that hard here, then

you can be assured it will not be my approach.

I will cover the boring and dry components of flowcharting and dabble a little with

pseudocode. From there we will move forward to some of the standard programming

situations. This will let you actually see logic in action. It will also allow some

images to sink into your brains. From there we will move forward into the general

approach of application design.

This may be a book whose later chapters you wish to read two or three times,

especially if you are new to IT. Nothing you do in your career will save you more time

and anguish than allowing the career advice chapter to fully settle in. Trust me on this

one. My first year in college I had to take a class on logic. We had two little paperback

books. One for flowcharting and one for pseudocoding. Needless to say we completed

those in the first month. The entire rest of the semester was class participation. Each

session would start with a new problem usually and the entire class would be spent

with students calling out or suggesting the steps of logic required while the instructor

drew with chalk. Admittedly, he had it rough for the first few days of that, but once

the bit was set in our teeth, all he had to do was draw and try not to inhale too much

chalk dust.

I dont have a classroom setting for you, nor do I wish to create one. Im sure

someone reading this book will do that in the end. What I do have is nearly two

decades of software development experience to draw on when creating problems for

you. There will be no choice but to start you out with some of the fluffy ones, but I plan

to leave you with some really good ones toward the end.

One thing that was always done in the past was to separate analysis and

programming logic classes. Now that Im long in the tooth, so to speak, I dont agree

with that separation. I wont go into all of the high-minded and far-reaching concepts

of application and systems analysis. There are an awful lot of other diagrams and

specification refinement methods. If you learned them all, each project would have you

burning a week up front deciding which method was going to work best for the current

project. I will take you through the common sense approach, naturally extending

program logic to application logic to systems design logic.

I-6 Introduction

I.5 Who Should Read This Book?

Anyone who has even the slightest interest in software development or needs to

manage the software development process should read this book. If you are

contemplating a career in software development, then this should be one of the first

books, if not the first book, you read before going too far down that career path.

Understanding the most fundamental concepts of the software development process

is critical to success in either of those career paths.

I.6 Why is Flowcharting and Pseudocoding Shunned?

Ill be honest. I havent drawn a program flowchart in nearly two decades. The

only time I write what could be called pseudocode for a module is when I have either

a really big chunk to chew or Im writing a bid for approval. Notice that I specifically

stated program flowchart and pseudocode for a module. The devil is in the details.

When doing application or systems design work, I either draw or participate in the

drawing of flowcharts for each project. Once you get into VLA (Very Large Application)

or system level designs, you have absolutely no choice. The human mind was not

meant to remain stretched around designs of that magnitude for prolonged periods of

time. Normally, projects of that size take six months to a year before they even get

close to a testing stage. You need really good diagrams to remember what it was you

intended to do six months ago so you can set up useful test conditions.

As you progress in the field if IT, you will begin to understand why companies will

spend in excess of $10,000 for an ink jet or plotter that uses rolled paper three to four

feet wide. One system I helped develop in the past few years had a system flow

diagram done from a very high level so management could understand it. It took two

sheets of that paper six feet in length taped on the long edge to contain the diagram.

When it was scaled down to print on regular letter size paper on a normal ink jet it

took close to a dozen sheets of paper taped edge to edge, and that was using fonts no

larger than six points inside of the symbols. You couldnt read it if it was more than

a foot from your eyes.

Program flowcharting has been shunned because it is a lot of work. A flowchart

is only good before you write your first line of code. Once you start testing, you realize

there are problems with your design and start making changes to the program. The

flowchart never gets updated. Bad documentation is worse than no documentation at

all because it leads people in the wrong direction. In the early 80s many shops still

endeavored to keep their flowcharts current. Once management got involved and

started chanting cut costs, flowcharts were the first thing to go.

Introduction I-7

Pseudocode was simpler. You could write it with any text editor or word processor.

In many ways it was much like COBOL. Some shops used to write pseudocode with

such detail that you could almost put a period at the end of each statement and get it

to compile. This level of pseudocode was impossible to maintain and also died after

hearing the cut costs mantra. High-level pseudocode still gets written in quite a few

shops. It usually gets wrapped in a word processing template that calls it a program

specification.

In days of old, a new programmer would be given a program specification from a

systems analyst, or just an analyst. That specification would range in quality from

incredibly detailed specifications you could begin coding from, or just a few lines

scribbled on a napkin with a sweat ring from a beverage on it. Laugh all you want at

that statement. The most complex systems you will ever get involved with start out

as just a few lines on a napkin. They generally take about five years to settle into a

company and become stable. The reason you end up working on them is they look so

simple and innocent being only a few lines on a napkin.

Once a programmer received a specification for a new program, they would sit

down with pencil and paper drawing out a very detailed flowchart. This flowchart

would document close to every line in the initial version of the program. They would

not be allowed to start coding until the analyst reviewed the flowchart completely and

agreed it was correct. When the analyst was too busy to bother with you, they would

reject the flowchart outright with the phrase Needs more detail. This statement was

designed to tick you off for a day or two until the analyst had time for you. It really

didnt have much to do with what you had done. How do I know this? I was once one

of those flowchart drawing programmers who got a flowchart rejected with that exact

phrase. A week later I submitted that exact same flowchart and it was accepted.

During that week I did flowcharts for the other analysts because they had time to chat

with me.

Developers who paid their dues got to be programmer analysts. These were the

cherished job titles. Once you became a programmer analyst you never had to draw

another program flowchart. You got to code straight from the specification. When the

specification was only a few lines on a napkin you got to work with an analyst to flesh

out the specification. Developers werent allowed to reject a specification from an

analyst with the phrase Needs more detail.

The result was that everyone wanted to be a programmer analyst. Everyone

wanted to just throw code at a problem and see what sticks. That was the fun job in

IT. Some geeks prided themselves on how close to the metal they could code. Even if

the shop had chosen BASIC or COBOL, they would find a way to toss in some

Assembler code just to prove how much of a geek they were. The fact that the

Assembler code could never port to a new machine, even in the same family of

computers, never stopped the geek of geeks from throwing it into the application.

I-8 Introduction

During your stint as a programmer analyst, you would get to cut your teeth writing

program specifications. Because you werent a systems analyst, your specification

could never be three lines on a napkin. Normally you would be the one receiving three

lines on a napkin and be told to flesh it out. Then your specification would have to be

reviewed by an analyst or systems analyst before it would be assigned to a

programmer.

Life would then take an ugly turn for you. After one to five years as a programmer

analyst you would be promoted to analyst. It was the only way to get further pay

increases. You would also be relieved of writing any more code. Instead, your life

would be application specifications and programmer management. While you would

toggle between writing systems specifications and application specifications, you would

never really do systems design. The task of systems design fell to the systems analyst.

When it came to bidding on contracts or very large applications, they would have to

draw a system flow diagram showing how all of the pieces were to fit together. Filling

in the actual details would fall to those below. The only code you would ever get to

write was the occasional operating system command script.

Most programmers went into IT not only for the money, but because they really

liked the idea of coding up solutions to problems. Once they got to the skill level of

programmer analyst, most would change jobs. Indeed, the average length of stay when

I was at that level was two years. Developers who loved to program simply didnt want

to give it up. The only way to avoid it was to leave the company.

Never let it be said that marketing wont sell you a product that will kill you.

Along came case tools followed by pick and drag code generators. They would market

these products claiming great leaps in productivity. The tools would have an interface

so appealing that even an MBA could generate the sample contact manager program

in under half an hour. That poisoned apple sure tasted sweet to upper management.

They threw tractor trailers full of money at the vendors of those products. Once PCs

with graphical desktops came out, an even bigger slew of visual type tools flooded the

market. Every one of them promised to make programmers more productive. Every

one of them cost the industry more than will ever truly be known.

The argument was made on college campuses that students would never have to

flowchart in real life, so why make them do it now? Grading those flowcharts certainly

took a lot of time. Drawing flowcharts was a lot of work. It was agreed that flowcharts

would be dropped. Because pseudocoding was taught in the same class as

flowcharting, it died a death by association.

Perhaps the saddest part of this story is that nobody with any clout stood up and

answered the question Why make them do it now? Had anyone answered that

question, it wouldnt have been dropped. Specification writing would have been added

to each and every language/tool class added to the curriculum and IT would have

remained a shining star instead of a downwardly spiraling industry.

Introduction I-9

Flowcharting is shunned because it is a lot of work. College students want to do

nothing but party when they first get away from home. Nobody wanted to spend their

evenings with a table full of eraser crumbs, which is pretty much what a class

requiring flowcharting made of their evenings.

Flowcharting is shunned because management didnt want to eat the cost of

training a developer who was only going to spend two years at their company. They

expected colleges to do that. When colleges failed, they threw money at tools to

eliminate the need, or so they thought.

Flowcharting is shunned because this is a Visa/MasterCard society. Buy now, rack

up enough debt to declare bankruptcy, and avoid paying altogether.

Pseudocoding at the program level died with flowcharting. It survives in a watered

down form at the much higher level of program specification. Until you see actual

application pseudocode, you wont understand just how watered down it is.

Nobody wants to pay their dues. That first year of flowcharting is horrible. If you

dont drink, you will find yourself starting. The first few months are bad because you

arent any good at logic then. You understand some of it, but dont really know how to

put it all together. By the end of the first year, you were approaching the level of

quality the IT industry needed: The kind of individual who could hear a problem and

begin the design in their head. Not an entire application or system problem, but a

single module or program problem. You would find yourself looking forward to hearing

newer developers ask, How am I supposed to do this? Turning around with a smile

you would say It is accomplished this way and give a detailed verbal explanation.

You looked forward to that day because that was the day all would know you had paid

your dues in full.

Flowcharting is shunned because nobody wants to pay their dues.

I.7 Flowcharting and the Current State of IT

Admittedly, this section probably belongs in one of my Ruminations chapters, but

it fits here. There are few uglier tasks in the world of IT than being asked to draw a

flowchart. While it may take you months to track down a bug in a particularly nasty

piece of code, there is an immense sense of accomplishment that follows fixing it and

pointing the fix out to all of those programmers who shied away from the task. When

you are asked to draw a flowchart for a large program, it can feel like being asked to

lug rocks from one pile to a new pile ten feet away, then lug them back again.

I-10 Introduction

Flowcharting is a mental training tool that must be endured. There is no other tool

that will condition your mind to be ready for a life in IT. Flowcharting is not a useful

learning tool unless you have a seasoned developer who will take the time to actually

review your flowchart and critique it. I can give you the fundamental examples. There

was a method to the madness in the job title hierarchy.

Every year for the past two decades, fewer and fewer students have been asked to

endure it. The result has been that fewer and fewer competent developers have

entered the IT job market. We are not talking about the total body count here, just the

percentage of that body count that actually has employable skills. Most of those

developers went straight into coding at shops without any mentor. During the ga-ga

days of massive IT growth, shops that were either low paying or just true Hell holes

to work at had turn over rates that exceeded 100%. Some shops today are Hell holes

which find themselves in the same situation. While the developers who never learned

logic or flowcharting became better at the syntax of the language, they found

themselves failing miserably once they were promoted higher in the company.

Systems analysts have been moved into infrastructure roles and analysts are now

doing everything the systems analysts used to do as far as software design. I am of

course talking about shops that still have analysts. Most have made that a task of the

IT department manager.

The reality is that most of the IT professionals who actually took a logic class that

required flowcharting and pseudocoding are approaching retirement. They are as high

in the IT shops as they can get. The staff under them, while technically competent and

knowledgeable about the business, hasnt focused on logic. They have focused on

enhancements and the occasional new program for the past 10 years. While they know

the existing system very well, they have never really been taught how to design or

build one from scratch.

We, as an industry, are already seeing the fallout from this. Skilled coders are

being forced into management roles where every new functionality request becomes

an enhancement to the existing system rather than a new system design. Systems,

which were originally designed to do only a few things really well, have now evolved

into a monster performing 20 to 30 completely unrelated tasks. Some companies have

already imploded because they were unable to respond to new information requests.

You, as a reader of this book and a student, are in a unique position. It is quite

possible that you will go straight from graduation to junior analyst role, completely

skipping the coding portion of this industry. Companies are playing a game of grab

right now searching for the cheapest indentured servants they can buy for the coding

portion of projects. Most of those projects end in utter failure that must then be

hidden, both publicly and in the books. What is missing from their mix is logic. The

coders they are hiring for $10/day havent been skilled in logic. The highly skilled

programmers they are tossing out didnt have it in school either, but they have had at

Introduction I-11

least a decade of experience so they dont make large blunders at the program logic

level. They do, however, stumble at the application and system design level.

In days gone by, what saved the system analyst when they wrote a three line

specification on a napkin was the quality of people under them. Everyone was trained

in logic. Everyone knew what had to be done to make it work. The project succeeded.

What happens now is upper management issues a one line spec on the back of a

napkin. The analyst issues a 12 or fewer page design document that was always good

enough before. The coders who havent got a clue about logic hack something together

and deliver it. Then everybody stands around pointing fingers while eyeing the black

smoking hole in the ground where the project was supposed to land.

I.8 Additional Reading

If you like the style and readability of this book you may like to read two additional

books written by myself. They should be appearing or have appeared in the

marketplace by the time this book is published. You need to read these two books in

order as they build upon each other. The Minimum You Need to Know to Be an

OpenVMS Application Developer ISBN 0-9770866-0-7. The Minimum You Need to

Know About Java on OpenVMS Volume 1" ISBN 0-9770866-1-5. Being the author, my

opinion of them is somewhat skewed.

I-12 Introduction

Page left blank intentionally.

Chapter 1

Basics of Flowcharting

1.1 Flowcharting Symbols

When you are drawing program or function-level flowcharts, there are only a

handful of symbols you need to concern yourself with. As you move onto application

and system flow diagrams, you encounter additional symbols. It seems each new tool

for laying out system flow diagrams adds a few symbols or changes the meaning of

them. Unless you stick to universal basics, system flow diagrams become very difficult

for anyone who is not a techno geek to follow. The goal of a flowchart is as much to let

the end user or customer see how things will work as the developer and IT types to

envision a solution. Some of the tools on the market lose sight of that. Be careful

when choosing programs to draw flowcharts for you.

Start/End

Terminator

Hello

World!

Screen

Output

Calculation or

Assignment

Report

Hard copy

output

Keyboard

Manual Input

?

Decision

Do_things

Internal

Predefined

Process

do_something

External

Predefined

Process

A

Connector

IO

IO

Operation

B1

Off Page

Connector

Collate

1-2 Chapter 1 - Basics of Flowcharting

A good many of these symbols you will never use. There are even more symbols

that I simply didnt provide. In part I didnt provide them because they are not built

into WordPerfect. The other part is quite simply that they dont come up that often at

the program or application level.

The last two symbols probably have some of you laughing and asking if I can still

wear underwear or now need Depends. You have to remember that flowcharting

started when developers had to work close to the bare metal. Many of us

programmed in Assembler. This was as close as you could get to the machine

instructions without hand entering octal values. (Dont worry if your eyes glazed over

on that, you dont need to know it, just understand that it was laborious and difficult.)

Back in those days, a computer had to be set up to run a program. In many cases

we didnt even have full-blown operating systems. There were independent card

reader subsystems, paper tape subsystems and, if your company had oceans of money

to burn, a magnetic drum. When you flowcharted a program, you had to flowchart

the entire execution. Hence, we have the Manual Operation symbol where you would

instruct the computer operators to configure card readers, tape punches, etc. In many

cases you would tell the operator to load a set of cards in front of your set of cards or

your paper tape that would actually load the subsystem of the device(s) you needed

into core. Memory wasnt called RAM back then, it was called core. The reason is

it actually was a magnetic core. It wasnt until much later that RAM came along,

followed by DRAM and a host of other types of RAM.

Sort

Extract

Merge

Connect

Drive

Manual

Operation

Punched

Card

Punched Tape

Chapter 1 - Basics of Flowcharting 1-3

Here is an odd little tidbit for you. Any idea what the ticker tape was in a ticker

tape parade? It had two sources. The first source was the brokers and stock

exchanges. A paper tape device would print bid, ask and last sale for stock symbols as

transactions happened. It wasnt printing like you would think of today. Every time

it printed it would make a ticking noise. This lead the industry to call the minimum

price movement for a stock the tick size. Our second source of ticker tape was

abandoned paper tape from computer rooms. Because the financial markets were some

of the first businesses to use computers outside of the military, this made sense. Now,

when people hold a ticker tape parade, they have to buy confetti.

As subsystems became better and better, they began to get standardized. The

standard groupings of these subsystems came to be called operating systems.

Computer memory started to get quite large in the 1970s. Digital Equipment

Corporation (DEC) produced the PDP line of computers which had 64 K-words

addressable and around 2 MEG of memory installable. That is correct, words. Bytes

are 8 bits and words are 2 bytes. Today, most systems measure RAM as some grouping

of bytes, so in todays terms it would be 128K. In todays world, compilers from

Microsoft can barely create a program that prints Hello Word! to the screen using less

than 128K, but back then we ran 30 to 64 users on a machine with that much.

Operating systems began providing utilities that programmers could use when

writing programs and/or applications. The most used of these utilities was the

SORT/MERGE utility. Every real operating system provides this utility. The Sort,

Extract and Merge symbols allowed us to show in our flowcharts that we planned on

using this utility.

The really old-timers would have a set of cards for input. They would indicate a

Manual Operation for the computer operators to load the cards into the stand-alone

Card Sorter and set the switches a certain way. Some time later they would come back

and the cards would be sorted. There would be another manual operation for the

operator to load the cards into one or more card readers and start the program. If you

were lucky enough to get all of your cards into a card sorter, it could perform a merge

for you by the simple virtue of sorting the entire bundle.

Disk drives turned Sort, Extract and Merge into a software-oriented process.

Oddly enough, the Extract feature became the front-end process for Sort. As

operating system sort utilities provided more and more functionality, they came with

various methods for creating either sort specification files or sort specification

parameters. Both sets allowed you to indicate which records you wanted the Sort

utility to actually process. Typically, once you defined the key for the sort (i.e.

account number, last name, etc.), you were allowed to add some sort of selection

qualifier for that key. The sort utility created a temporary file with the records you

selected, then it sorted those. It didnt take long for people to figure out that if the

temporary file name could be specified and Sort could be made to stop after creating

it, then you just didnt need to write extract programs.

1-4 Chapter 1 - Basics of Flowcharting

Collate is an odd little symbol. As I recall, it started as a manual operation for

operators to organize bundles of cards to be broken up between multiple card readers

(too many for a single card reader). Then it morphed into being used for organizing

reports that were printed on different printers. The last I remember it being used was

for the massively expensive all-in-one copy-print machines. This was way before your

sub $300 all-in-one copy-fax-print machines came out. We are talking about massive

high speed printers that sometimes had copy functions built in. A collation device was

hung on it that could sort and store anywhere from 12 to 30+ copies. Before we had

really good printer control languages, the computer operator running the batch job had

to ensure the printer was set to collate. He or she also had to sit there and pull out the

reports as each tray got a completed one.

Let me explain the collate function a little bit more. Prior to printing systems that

could bundle their output directly into an envelope stuffer, it was important. If you

had a charge account with someone, you wanted to be the only one who got your

statement. In the days of continuous form printing and hand collating, this wasnt

always the case. The collating device ensured that only your statement was on that

tray, assuming the operator got the tray empty before it had to be re-used by the

printer. The operator would either hand fold and stuff it or hand carry it to the

stuffing machine.

As long as we are talking about odd computer hardware and terms, let me drop a

couple more on you: burster and decollator two of the noisiest machines to ever find

their way into a computer room. It wasnt good to handle all of this paper in a

computer room, but the printers of the days needed the additional cooling found in the

computer room. A burster would separate continuous form printouts into single

sheets. You had to tell it the length of the form and start the form feeding from the

correct way, then it sat there popping apart the perforations between pages. When you

fed a report in, you had to feed it in backwards or facing the other way because the first

sheet would end up at the bottom of the pile facing exactly the way it faced coming in.

More than one newbie computer operator got to spend their afternoon turning a report

around after feeding it in the wrong way.

The decollator was probably my favorite. These machines were an OSHA

(Occupational Safety and Health Administration) disaster waiting to happen. Many

things that got printed by computers back then, and even to some degree today, needed

to be printed in multiple copies. Today, people buy elcheapo ink jet printers and just

print multiple copies, then hope for the best if they end up in court. What big business

did was print on multi-part form, normally somewhere between two- and five -part

forms. This meant that the exact same pre-printed form occurred that many times in

a single perforated section. Early on they came with carbon paper between each sheet

and later simply used self-duplicating pages. Once printed, the operator hand peeled

the tractor-feed edges off the forms, then fed it through a decollator. The decollator

had a stacking channel, or bin, for each part of the form and had these spinning

slotted shaft-type things to wind up the carbon paper. They were the perfect tie

Chapter 1 - Basics of Flowcharting 1-5

catcher. I honestly think we avoided a lot of deaths in the IT industry by having the

female operators run the decollator. It was a fair trade. They usually made the male

operators lose their hearing running the burster. Dress codes seemed to always make

the guys wear ties.

The off-page connector is just what you think it is. When you run out of room

on a sheet of paper, you put one of these on the end of your line and put a label in it.

You use the same connector and label on the start of the continuation page.

Our IO Operation symbol is used when reading or writing to files and databases.

You use the hard copy output symbol when writing to a report file and the screen

output symbol when writing to the terminal. When accepting input from the user, you

use the manual input symbol.

The connector is usually a much smaller circle than I have drawn here. I needed

to make it large enough to get the caption under it without a line break. Whenever you

have multiple lines that need to intersect, you are supposed to use a connector.

Instead of having 15 arrow heads going into one box, you mash the 15 arrow heads into

the connector and have one line running from the connector to the box. (Dont worry,

you will understand before this chapter is over and not a lot of people do it.)

Another use of the connector is the labeled connector as I have shown you.

When you are drawing a large flowchart, it is not uncommon to find yourself on the

other side of the diagram needing to return. You can either create the worlds ugliest

multiply bent line crossing over all other lines, or you can use a nice short line going

to a labeled connector. You then use a labeled connector having the same label where

you wish to return.

I used to flowchart on the back of continuous form. It was not uncommon for me

to have single module flowcharts that were seven pages long. When you had a lot of

things to do in a processing loop before you read your next record, there was simply no

other way to get back to your input statement.

External predefined process encompasses operating systems library, home

grown library and system service functions. In todays world it also indicates stored

procedures in a database engine. Ordinarily you just put the name of the procedure

in the box. When drawing by hand I would put the name in the small area at the top

of the symbol. A lot of electronic tools dont give you that option.

Internal predefined process gets kind of tricky to define. Most people give you

the purist definition, then bank heavily on you not flowcharting in the real world.

It is a good bank in this day and age. The purist definition is you use this to indicate

a subroutine that is a separate flowchart, but written as part of this program.

Depending on the language used by your programming shop, this either worked for you

or put you in a world of hurt.

1-6 Chapter 1 - Basics of Flowcharting

Look back at the explanation for external predefined process. See that phrase

home grown library? That is where the hurt comes in. Some programming

languages enforce making every subroutine or function you write callable from

anywhere. Some languages force you to decide at creation time whether your

function/subroutine will be accessible from other programs. The hurt comes, not at the

time of creation, but later in life. As you write more programs and others learn about

your function/subroutine, it gets re-used. This means it gets placed in the home

grown library. Your program didnt change, but your flowchart is now out of date if

you are using the purist definition.

The decision symbol has some odd uses. The normal use is single condition if

testing. Usually there is just a Yes and No (or True and False) branch coming out of

it. Fight off the temptation to give it wings. Have one line come out the bottom and

the other come out a side. Using the side points for each condition only looks good in

very short examples. When drawing out larger logic diagrams, it paints you off the

page pretty fast.

I said it has some odd uses. They arent really odd, they just look odd to those

unfamiliar with them. Most computer languages today have what is known as a

switch, select or evaluate statement. The general explanation for these statements is

that you do different things depending on the value of one variable. The variable name

gets placed in the decision symbol, then you draw a line with a lot of drop points off it

and label each drop point with the variable value. It drops into the action to be taken

for that value. Dont worry, I will provide an example later in this text.

Our calculation/assignment box is pretty much what it sounds like. In it you

will find statements like SALES_TAX = NET_SALES * TAX_RATE. Dont worry if you

dont understand those names, as understanding them isnt a big hurdle.

Terminator should be the most straight forward symbol in flowcharting. It has

caused more heated discussions than any symbol I know. You use one of these symbols

to start your flowchart and another to end your flowchart. Shouldnt be a problem,

right? Guess again. The problems surface around what goes inside of the symbols.

Some camps became quite religious about using EXIT when the module is stand-

alone and others just as deeply convicted about END. They argued strongly that EXIT

should only be used for subroutines that do not return a value to their caller. Save

your laughter, it gets better. Functions which return a value had some equally divided

camps. Some believed strongly that it should be RETURN RET_VAL where RET_VAL

was the name of the variable containing your return value. Others believed it should

just be RETURN and the documentation for the function should stipulate the return

value. One camp believed it should be EXIT RET_VAL because whatever language

they were using for programming actually ended a function with that syntax. A small

group of FORTRAN programmers used to champion the idea of the ending symbol

Chapter 1 - Basics of Flowcharting 1-7

being left blank. This was because in FORTRAN you assigned the return value to the

function name and the code simply stopped.

Do you really want me to go into the arguments about the content of the starting

symbol? We are just going to use START for stand-alone modules and ENTER for

callable routines. Sometimes I will slip and use START all of the time. I will use

STOP, EXIT, END or RETURN as I see fit on the last terminal. Please forgive me.

As I stated earlier, there are symbols I didnt cover. Some things we will cover

later as I take you further into logic, and others you will need to pick up on your own.

Knowing what the symbols are wont do you much good if you dont know how to use

them.

1.2 Linear Sequence

You will draw many small sections of flowcharts

that use the linear sequence. It is a tool you use to

build other tools. By itself it is of little use.

In this example I chose to show you an

unexpected use of the IO symbol. Before you can

read from a file, the file must be opened for input.

Back in the day, many shops were adamant about

seeing both the open and the close clearly defined in

the flowchart.

All we did with this example is:

Open an input file

Read a unit of IO from it

Display that unit of input

Close the file

End the program

It is very important you understand why I

phrased Read a unit of IO the way I did. Computer

files can contain a wide variety and organization of

data. In this example I didnt include any

information about the file type or organization. Some

shops had a separate document that contained that

information. Others had you put it in the comments.

I have to start you somewhere, so this is where Im

starting you.

1-8 Chapter 1 - Basics of Flowcharting

My display input symbol doesnt have any preceding symbols that would convert

binary data to display format. For the purposes of this discussion, you must assume

that the input file has one line of readily displayable ASCII text. (If you dont know

what ASCII is, please take some time and search the Web for the definition and

history.)

As you progress in the field of IT, you will encounter indexed files. These are files

which contain both text and binary data organized in records. They will have one or

more keys on them. A key is one or more fields defined at file creation time to be

an index into the file. An index is used to quickly get to one or more records in the

file. If the index is defined to identify only one record in the file, then it is called a

unique index. This also translates into a unique key. Most index file systems

require, some just recommend, that the first key defined for a file be a unique key. The

first key is also usually called the Primary Key. Ordinarily, when you access a file

via its primary key, you want to get exactly one record. The record that matches the

key value you passed in.

I know Im getting a little deep here this early in the text, but please plod through

it. Ill give you a small example later in this book. The point Im trying to make right

now is to be very careful about how you phrase things with respect to file IO.

Chapter 1 - Basics of Flowcharting 1-9

1.3 Top Checking Loop

You are looking at one of the most

implemented logic structures in IT, the top

checking loop. Every 3GL (Third Generation

Language), most Object Oriented and many

4GLs (Fourth Generation Language) provide

this very logic structure. Many provide it in a

single statement like a for or while loop.

Quite simply, you initialize a variable to

some value. At the top of that loop you check

the value against some condition. Normally

this is a known maximum, but it can also be a

known minimum. In our case, X must be less

than or equal to 10 to continue. Ten is our

known maximum.

Inside of the loop there is always some

quantity of logic that gets performed. From the

loop perspective what happens in there is of

little importance. The one and only

requirement is that your loop counting variable

must be adjusted prior to returning to the top

of the loop. Because we are checking against a maximum, we added one to the loop

counter. If you are working your way down to a minimum, you would subtract a value

from the counter variable.

Let me speak about convention here. Forward flow always runs down the page.

Return branches are always drawn on the left. Forward branches either go down or

to the right. Most instructors would not let me have the end terminal stuck out to the

right like that. They would make me place it at the bottom of the page and connect my

arrow to it. Some people are quite picky about the placement of this terminal. Id

rather be picky about how much logic you learn.

Some of you may be wondering how I created these flowchart images because they

are much smaller and somewhat different from the images I presented initially. The

first images came directly from WordPerfect. To save space and speed things up I

purchased a copy of Flow Diagrams Software http://www.anydraw.com. I didnt do

a large quantity of analysis. There are a lot of shareware products out there which

draw flowcharts. This product cost me around US $30.00 and let me save flowcharts

as JPEG files to import into WordPerfect. Your instructors may make you draw things

by hand with a plastic template. No great crime there, I did it for two years. Back

then I think I spent $30.00 and got a good 0.05mm pencil. They had just come out and

werent common enough to be cheap. (I told you, Im old!)

1-10 Chapter 1 - Basics of Flowcharting

There is a variation of the this loop that does not use a counter variable, it uses a

flag variable. Many professors and books will call this a boolean variable. From the

logic perspective, it doesnt matter what you call it, and the data type may be

preordained by your choice of implementation languages. To use this variation you

initialize a variable to a known value (TRUE, FALSE, 0, 1, etc.). The test in the

decision symbol checks for an equality or inequality. You typically set the flag to

another value based on some condition which may be triggered from outside resources.

Sometimes it becomes what is really a middle checking loop.

Chapter 1 - Basics of Flowcharting 1-11

1.4 Middle Checking Loop

You will notice a symbol you havent seen before in the image on the left. This is

the symbol that once meant tape input. Many drawing programs, including the one

Im using, now use it to indicate sequential data.

Pay attention to the dashed lines running from the tape symbol to the IO symbols.

There are a lot of different rules about this, depending on where you go. Some places

want the dashed line to have no arrow heads. Some only want dashed lines to the open

and close. They mandate you put the actual record name in the other IO symbols. I

dont really like the file symbol to appear at all when working at this level. When

laying out the flow for an actual program, we used to create a data legend page that

contained the disk drive symbol, name of the file, organization of file, keys and method

of access (read, write, update or delete). Each file would be given some hokey little

code like #1, #2, #3, etc. Because the symbols were small, we would use the codes

inside of the symbols. When we were drawing flowcharts for BASIC programs the

1-12 Chapter 1 - Basics of Flowcharting

numbers directly corresponded to the channel numbers we would use in the programs.

Take a close look at the above diagram. Where do I ever set EOF to TRUE? The

answer is I dont. The error handling wrapped into the IO operation is going to set that

value for us. You probably do not know enough about software development to fully

understand that statement, so let me explain. Every language Ive ever worked with

(higher in the food chain than Assembler) provides some method of built in IO

exception trapping. Ive encountered people in the past who demanded you show this

in the flowchart. Going to that level really is a bit much. COBOL has an AT END

clause on its read statement. BASIC tosses BASIC ERROR 11. C provides the feof()

function so you dont even declare the EOF variable we used in this diagram. Most

developers are smart enough to understand EOF means End of File. If you have more

than one file use something like EOF_name or EOF_#2.

Take a look at my decision symbol in this diagram. I didnt label the branches.

Most instructors will slap you pretty hard for that. Many instructors want you to put

simply EOF in the decision symbol then label the branches TRUE and FALSE. It will

be up to your instructor to set the ground rules. My focus is getting you to visualize

the logic you need. The finer details about drawing it dont interest me that much. As

long as you can see it in your mind, you will be able to code it when you move onto

programming.

When it comes to the middle checking loop, most academics will hiss, cluck their

tongues and call it bad design. Those people have never worked in the real world for

a living. A middle checking loop is forced on us by language limitations involving IO.

If you want to make a politically correct loop that checks at the top, then you have to

code up two IO calls along with their complete sets of error handling. The first one is

executed only one time before entering the loop, and the last one is executed at the

very bottom of the loop. I have coded it both ways in my professional life. The rules

of the shop you work at will force the decision on you.

Take a look at the above diagram. If we made it a purist bottom checking loop, we

would have to add one more IO symbol after do something. Then we would have to

find a way to get the dashed line from the sequential data symbol over to it, or we

would have to make an additional copy of the sequential data symbol. Either way, a

little bitty loop would start to get messy.

You are now beginning to understand why every programmer must cut their teeth

with flowcharting. While it is technically true that you wont physically draw a

program flowchart in the real world, you will draw little pieces in your mind as you are

writing.

Chapter 1 - Basics of Flowcharting 1-13

1.5 Bottom Checking Loop

I didnt perform any file IO in this example to keep it

simple for you. A bottom checking loop cannot really be

used when file IO is involved. A bottom checking loop is

used when you always wish to perform the loop contents

(instructions inside of the loop) at least once. With file IO

you have to handle the possibility the file will be empty,

locked or missing.

Careful readers will note that in my previous example,

I didnt handle the condition of a missing file. Some

instructors will mandate you handle those conditions, others

will allow you to assume critical error checking is handled

by the actual program.

Critical error checking is the trapping and handling of

hard errors that normally wouldnt occur during program

run time. You must handle those errors from inside of your

program unless you consider letting the user see an ugly

stack dump on the screen acceptable.

Some operating systems will give you what is called a

stack dump when you dont handle a critical error or your

program has a logic bomb. Most of you have probably used

an operating system of feeble capabilities like Windows.

Putting it in terms you understand, it would be when you

see that lovely General Protection Fault displayed. When

the Windows developers themselves forget to handle critical

errors you end up with the Blue Screen of Death.

Flowcharting doesnt give us a good method of drawing out critical error handling.

It is one of the many arguments used against the teaching of flowcharting. You must

be taught flowcharting if you are to ever succeed in programming. What you learn

when you learn flowcharting is the logic to accomplish your task. Programmers who

start with drag & drop component tools never learn logic and tend to be of little use.

1-14 Chapter 1 - Basics of Flowcharting

1.6 Multiple Decisions

This chapter is now 14 pages in length and you have covered all of the core

fundamentals for program flowcharting. These are the basic building blocks which

allow us to create phenomenal designs. The next few examples will give you some idea

about how to hook them together. Later in this book we will cover some more involved

examples. Logic is the path you must take to get from point A to point B. These tools

are what you use to both build and see the path.

The first combination you need to be

able to visualize is multiple decisions.

The term multiple decisions really refers

to nested decisions. From a mechanical

standpoint they are pretty easy to draw.

Once you take a look at the example

to the left, you will begin to see my advice

about not giving decision symbols wings

wasnt just some stylistic preference. Had

I given my decision symbols wings, the

drawing would have quickly either gone

off both page edges, or had to be shrunk

down so small you couldnt make

anything out.

Nested decisions cannot be avoided.

The logic of everyday life tends to throw

us into situations that require them.

What you have to try avoiding are

situations like on Thursdays, when it rains, and Fred is at the keyboard, X happens.

Laugh all you want at my little expression. When you get farther along in your IT

career, you will be asked by your employer to implement something just as messed up.

The way you tell them they are idiots, without actually saying it to their faces, is

to have them flowchart the process. At first they will come back and tell you that is not

their job. If you are working for a big company, you can ask them to have HR send you

the process flow diagram for the manual task. That will pretty much point out they

never did a process flow diagram. From there the gopher will ride down the mountain.

Nobody will want to draw the process flow diagram. Resist all efforts by them to put

the flowchart creation on your back. Eventually their most junior person will be

saddled with the task. Some six to eight weeks later, after a bunch of meetings, the

request will simply go away. They will realize they have been idiots for a very long

time and will begin to look for a politically correct way out of the debacle.

Chapter 1 - Basics of Flowcharting 1-15

Both flowcharting and computer languages have had to deal with multiple

decisions for a very long period of time. Many methods have been created to handle

them in as sane a manner as possible. One such method is the

switch/select/evaluate/ON construct. I gave you multiple choices on the name because

you will get a different name depending on which programming language you end up

using. Some languages, like BASIC, give you two implementations. It provides both

an ON-GOTO statement and a SELECT-CASE statement. From the flowcharting

aspect, it is all pretty much the same.

When drawing one of these

constructs, it is important to either

specifically include a default/else

branch or add a document comment

as to why it wasnt provided. When

you use this structure, you can

replace m any nested decision

statements with one clean structure.

It is a very powerful tool.

Normally, logic is independent of

the programming language used.

Should you choose to use this tool,

you need to understand what

capabilities it has in the underlying

language. Most every language will

let you check a single integer

variable against hard coded

(constant) integer values. Some

languages will let you check string

variables, but others, like C/C++ will

not. Other languages, like BASIC

on the OpenVMS platform, will let

each case be a range and will check

them in the order they are provided,

processing the first true condition.

At this stage of your career, you

are probably thinking that and a

dollar will get him a soda out of the

vending machine. Write it down.

Once you progress to actual programming, you will be taught multiple languages at the

same time. When you go out into the real world you will support applications and

systems written in multiple languages. You will get burned during a design session

thinking you can use this tool for a string or a range, only to find out at

coding/compile time that you cannot. Write this day down and what you were told.

1-16 Chapter 1 - Basics of Flowcharting

Tape it to your bedroom mirror. Within two years you will suddenly be reminded of

it, trust me.

I really must belabor this point with an example. You take a job at a bank. The

bank wants you to write a stand-alone function that will return the current interest

rate based upon the loan amount. The interest rates change daily and are stored in a

file on the system. They will have the following groupings: Auto, small mortgage,

medium mortgage, large mortgage, jumbo mortgage and national debt. The maximum

value for each of these loan rates is stored on the record with the loan rate. The

variable names are given to you and will be globally accessible to your function.

How do you flowchart something like that? Here is where you have to know the

programming language you will be working with. The worst-case scenario is that you

have to brute force the function with nested decision symbols. If you are lucky enough

to be working with BASIC, your function flowchart will look much like the one above.

The decision symbol will contain LOAN_AMT. Instead of new you will have

Chapter 1 - Basics of Flowcharting 1-17

You cannot be a great software developer, nor even a good programmer until you

have walked the path of flowcharting. The act of creating flowcharts teaches you the

difference between good and bad logic. You can see the difference rather than be told.

When the flowchart you are looking at, or Heaven forbid, writing, ends up with dozens

of criss-crossed lines and branches that are impossible to follow, you begin to realize

this was a bad design. Many will try to say it is just a poorly drawn flowchart and in

some cases that will be correct. But the majority of the time its a bad design.

There will only be a few questions at the end of this chapter. Dont worry, Im not

going to ask you to memorize symbols. You learn them by using them and the focus

of this book is to provide problems for you and the instructor to solve during class.

These questions are designed to teach you that some of the most important details

seem insignificant the first time you are exposed to them. Welcome to your first real

lesson in logic.

1.8 Exercises

1. What is the main difference between a bottom checking loop and a top checking

loop? The answer has nothing to do with where the check is performed.

2. Under what circumstance must you choose a bottom checking loop over a top

checking loop?

3. On most of todays computers, what is the size of a byte?

4. What is another term for multiple decisions when they are dependant upon each

other?

5. When drawing a decision symbol, on which side does the loop back, return or

branch above line connect?

6. What is a program flowchart?

7. When would you use a middle checking loop?

8. What is a decollator, and why was it used?

9. Given a specification If a = 1 do_something, a = 2 do_something_else, a = 3

do_a_different_thing, any other value do nothing, which structure would you

draw?

10. When multiple lines need to enter a single symbol, which symbol should you use

to join them?

1-18 Chapter 1 - Basics of Flowcharting

Page left blank intentionally.

Chapter 2

Basics of Pseudocode

2.1 What is Pseudocode?

Pseudocode is basically a tersely worded English language description of the

algorithms to be implemented later in a programming language. In days of old, you

were told not to use words specific to a programming language. While that is good

advice, many of the words you need to use were implemented as verbs by a large

number of 3GL programming languages. Words like if, do-while and perform

have been implemented in one fashion or another by many of the languages you will

find yourself eventually programming in. As a consequence of this: Most pseudocode

looks a lot like COBOL code.

You will find pseudocode still in use at many shops, but not as it was originally

intended. It now exists primarily in sections of systems specifications. When an

analyst writes a specification for a new and large system, there will inevitably be

several areas where tricky algorithms or formulas are needed. Were this formula

simply named or written as a paragraph of text, they would be open to interpretation.

To remove that point of failure early on, the analyst will provide the formula or

al