The Minimum You Need To Know About Logic To Work in IT

The Minimum You Need to Know
About Logic to Work in IT
By Roland Hughes
Logikal Solutions
Copyright 2007 by Roland Hughes

All rights reserved
ISBN
ISBN-13
0-9770866-2-3
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 dam age, 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
VSAM
CICS
SyncSort
SyncSort Incorporated
MQSeries
MySQL
MySQL AB
Unix
The Open Group
Linux
Linus Torvalds
ACMS
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 em bark on a career
in IT. Having spent nearly 20 years in this industry m yself, 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 m y attem pt to pass som e of the
m ost im portant, yet least taught, know ledge onto you, the reader.
W elcome 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 w ill create diagram s and pseudocode, there w ill be nothing you can
actually com pile and run.
Table of Contents
Introduction.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.1 W hy Logic?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.2 W hat is Logic?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.3 Prerequisites for This Book. . . . . . . . . . . . . . . . . . . .
I.4 Approach of This Book. . . . . . . . . . . . . . . . . . . . . . . .
I.5 W ho Should Read This Book?. . . . . . . . . . . . . . . . . .
I.6 W hy is Flow charting and Pseudocoding Shunned?.
I.7 Flowcharting and the Current State of IT. . . . . . . .
I.8 Additional Reading. . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. I-1
. I-1
. I-2
. I-4
. I-5
. I-6
. I-6
. I-9
I-11
Chapter 1. . . . . . . . . . . . . . . . . . . .
Basics of Flowcharting. . . . . . . . .
1.1 Flowcharting Sym bols. . .
1.2 Linear Sequence. . . . . . . .
1.3 Top Checking Loop. . . . . .
1.4 Middle Checking Loop. . .
1.5 Bottom Checking Loop. . .
1.6 Multiple Decisions. . . . . .
1.7 Flowcharting Sum m ary. .
1.8 Exercises. . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-1
1-1
1-1
1-7
1-9
1-11
1-13
1-14
1-16
1-17
Chapter 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basics of Pseudocode. . . . . . . . . . . . . . . . . . . . . . . .
2.1 W hat is Pseudocode?. . . . . . . . . . . . . . . . . .
2.2 Rules of Pseudocode. . . . . . . . . . . . . . . . . . .
2.3 The W hy and W hen of Pseudocode. . . . . . .
2.4 How Do You Learn to W rite Pseudocode?.
2.5 Linear Sequence. . . . . . . . . . . . . . . . . . . . . .
2.6 Top Checking Loop. . . . . . . . . . . . . . . . . . . .
2.7 Middle Checking Loop. . . . . . . . . . . . . . . . .
2.8 Bottom Checking Loop. . . . . . . . . . . . . . . . .
2.9 Multiple Decisions. . . . . . . . . . . . . . . . . . . .
2.10 Pseudocode Followup. . . . . . . . . . . . . . . . .
2.11 Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-1
2-1
2-1
2-1
2-2
2-2
2-3
2-3
2-4
2-5
2-5
2-7
2-8
Chapter 3. . . . . . . . . . . . . . . . . . . . . . . . . .
Som e Fundam ental Data Types.. . . . . . .
3.1 Core Data Types. . . . . . . . . . . . . .
3.2 Data Type Sizes. . . . . . . . . . . . . .
3.3 Variables. . . . . . . . . . . . . . . . . . . .
3.4 Arrays. . . . . . . . . . . . . . . . . . . . . .
3.5 Records and Structures. . . . . . . .
3.6 Indexes. . . . . . . . . . . . . . . . . . . . .
3.7 Record and Structure Exam ples.
3.8 Sum m ary.. . . . . . . . . . . . . . . . . . .
3.9 Exercises. . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-1
3-1
3-1
3-3
3-5
3-6
3-7
3-8
3-12
3-15
3-16
Chapter 4. . . . . . . . . . . . . . . . . . . . . . . . . . .
Searching and Sorting. . . . . . . . . . . . . . . .
4.1 Overview. . . . . . . . . . . . . . . . . . . . .
4.2 The Bubble Sort. . . . . . . . . . . . . . .
4.3 Class Exercise One. . . . . . . . . . . . .
4.4 Linear Search. . . . . . . . . . . . . . . . .
4.5 Insertion Sort. . . . . . . . . . . . . . . . .
4.6 Class Exercise Two.. . . . . . . . . . . .
4.7 Class Exercise Three. . . . . . . . . . .
4.8 Shell Sort. . . . . . . . . . . . . . . . . . . .
4.9 Binary Search. . . . . . . . . . . . . . . . .
4.10 Class Exercise Four. . . . . . . . . . .
4.11 Leaping Lynn. . . . . . . . . . . . . . . .
4.12 Class Exercise Five. . . . . . . . . . .
4.13 W hen All Search Routines Fail. .
4.14 The Two Part Compare. . . . . . . .
4.15 Com paring Dates. . . . . . . . . . . . .
4.16 Sum m ary.. . . . . . . . . . . . . . . . . . .
4.17 Exercises. . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4-1
4-1
4-1
4-1
4-6
4-7
4-9
4-12
4-12
4-13
4-14
4-15
4-15
4-18
4-19
4-20
4-22
4-24
4-25
Chapter 5. . . . . . . . . . . . . . . . . . . . . . . . .
Decision Order. . . . . . . . . . . . . . . . . . . .
5.1 Choosing Your Decision Order.
5.2 Creating an Extract File. . . . . .
5.3 Class Exercise One. . . . . . . . . . .
5.4 Class Exercise Two.. . . . . . . . . .
5.5 Class Exercise Three. . . . . . . . .
5.6 Class Exercise Four. . . . . . . . . .
5.7 Class Exercise Five. . . . . . . . . .
5.8 Sum m ary.. . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-1
5-1
5-1
5-2
5-5
5-7
5-8
5-9
5-10
5-11
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Chapter 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowing W hat Questions to Ask. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 How are You Going to Use This?.. . . . . . . . . . . . . . . . . . . . . .
6.2 W ho is the Audience?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 W hat Business Areas and System s are Impacted by This?. .
6.4 Is This Legal?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.1 Exam ple One. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.2 Exam ple Two (Where Did You Get This?). . . . . . . . . . . . . .
6.5 W ho Owns This Project?. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 How W ill Success Be Measured?. . . . . . . . . . . . . . . . . . . . . . .
6.7 W ho W ill Sign Off on This Project?. . . . . . . . . . . . . . . . . . . . .
6.8 W hat are the Deliverables?. . . . . . . . . . . . . . . . . . . . . . . . . . .
6.9 How Much Tim e Do I Have?. . . . . . . . . . . . . . . . . . . . . . . . . .
6.10 How Reliable Does This Have to Be?. . . . . . . . . . . . . . . . . .
6.11 W hat is the Required Availability?. . . . . . . . . . . . . . . . . . . .
6.12 Sum m ary.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-1
6-1
6-1
6-2
6-3
6-5
6-5
6-6
6-8
6-9
6-10
6-10
6-11
6-11
6-13
6-14
Chapter 7. . . . . . . . . . . . . . . . .
Linked Lists.. . . . . . . . . . . . . .
7.1 Pointers. . . . . . . . . . . .
7.2 A Singly Linked List.
7.3 Doubly Linked Lists. .
7.4 W hich do you use?. . .
7.5 Exercises. . . . . . . . . . .
7.6 Class Exercise One. . .
7.7 Sum m ary.. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7-1
7-1
7-1
7-2
7-5
7-7
7-8
7-8
7-8
Chapter 8. . . . . . . . . . . . . . .
Hash.. . . . . . . . . . . . . . . . . .
8.1 W hat is a Hash?. . .
8.2 Collisions.. . . . . . . .
8.3 File vs. Algorithm . .
8.4 Sum m ary.. . . . . . . .
8.5 Exercises. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-1
8-1
8-1
8-2
8-4
8-5
8-6
Chapter 9. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relational Databases. . . . . . . . . . . . . . . . . .
9.1 W hat is a Relational Database?.. . .
9.2 Som e Im portant Relational Term s.
9.3 Data Integrity and Constraints. . . .
9.4 SQL and Flowcharting. . . . . . . . . . .
9.5 Sum m ary.. . . . . . . . . . . . . . . . . . . . .
9.6 Exercises. . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-1
9-1
9-1
9-2
9-5
9-9
9-12
9-13
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Chapter 10. . . . . . . . . . . . . . . . . . . . . . . .
Surviving the Fire.. . . . . . . . . . . . . . . . .
10.1 The Philosophy. . . . . . . . . . . . .
10.2 Beware the Deadly Em brace. .
10.3 The Stock Order Problem . . . .
10.4 Som e Career Advice. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10-1
10-1
10-1
10-3
10-4
10-7
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9
Introduction
I.1 W hy Logic?
I could start playing the gam e w ith you and respond with W hy not logic?, but it
is too soon in this book to tick you off; there will be tim e enough for that later. This
book cam e about for m any reasons. It is not one I originally intended to write as part
of this short series, if ever. M any circum stances coalesced to allow tim e enough for it,
but there still had to be a need for this book to justify writing it. The need cam e from
a very odd place (at least for those of you unfam iliar w ith the w ays of IT professionals):
conversations in bars.
Oh, this w asnt conversations w ith 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 som e aspect of IT. M y current consulting contract has
m e 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 m ost, one
IT student, but w hat they w ere being taught. Logic isnt required any m ore at a lot of
cam puses. 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 fundam ental core of application and
system design. Once you understand that logic is no longer being taught, it is easy to
understand the com plete 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-G UI back end applications flounder m iserably. W ere there any justice in
the world, they would be able to get their m oney back from the university which gave
them the degree.
W hen I obtained m y first degree som e 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 implem ent 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 . N either argum ent w as 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 sam e criticism from former
instructors. They claim ed that none of the newer students did very well later in the
curriculum . That a lot of students changed their m ajor when they started hitting the
m ore 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 3G L com pilers and syntax checkers. It was because
they had burned alm ost 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 sim ple system s design, were never covered. When they
got to the m ore advanced programm ing classes, they had no fram e of reference. They
did not know how to design a control break report, or even w hat a control break report
was. The last part is really sad considering how m ost college students have a credit
card. Every m onth they get a statem ent for their credit card account that is a control
break report.
W hy logic? Because you cannot hope to succeed or even survive in softw are
developm ent without it. Why logic? Because m ost of you have went through or are
going through a college curriculum that didnt teach you logic. W hy 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 programm er to your staff was m uch like buying a
new car. You got to pick and choose the features, but you never had to ask if the car
cam e with an engine. Program m ers from the old curriculum s all had been taught logic,
you didnt have to ask. In todays m arket, you have to ask if the car com es with an
engine.
I.2 W hat is Logic?

That is the fundam ental question. There are m any answers. Depending on the
situation surrounding the question, som e answers are m ore correct than others. When
you com plete 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. W hat is
logical?
No, Im not trying to lay a bunch of academ ic babble on you. People dont buy a
book they arent forced to read because they like having academ ic babble shoved down
their throats. I have found few things more boring than listening to what career
academ ics have said or reading w hat they have w ritten. There are several periodicals
that handle that m arket. There was a tim e in m y career w hen I believed I could obtain
som ething useful from them , so I paid expensive fees to read those m agazines. What
I obtained from them was a substitute for Nytol m ost of the tim e.
Introduction
I-3
Logic is the fundam ental tool of IT. It is the tool from which all other tools are
created. There are m any 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 sam e outcome.
That statem ent is incorrect. They will try to proof their statem ents with truth tables
and lectures that glaze over your eyes inside of 15 m inutes. Had there been even the
m ost rem ote grain of truth to those proofs AI (Artificial Intelligence) would have been
m ore than a m id-80s flash in the pan.
For logic to provide the sam e answer twice, given the sam e set of truths, you m ust
start in the sam e place each tim e. Logic isnt a set of gears producing the sam e output
every tim e 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 im plem entation failure. Every program
fails at som e point. Because we dont like to say we exist to create failure, we say we
exist to create software and som e of that software has bugs. It is probably a good thing
we call them bugs so the tool to rem ove them can be called a debugger, otherwise we
would be talking about running our programs through failure rem oval instead of
running them through the debugger.
Back in the beginning days of com puters, they were a collection of tubes and
programm ed by either wiring or tossing a series of switches. There was only one type
of logic: hardware. For m ost com puters it was the hard-wired truth. A switch was
either on or off. Some com puters, though few exist today, used frequency logic for
lack of a better term . They were analog, not digital. M ost of you reading this should
be fam iliar with the classic sine wave from your math classes: the perfectly
sym m etrical S laid on its side and a line draw n 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 m uch like real life. It allowed for varying degrees of
true and false. Som e of you using digital cam eras m ay have heard a term called fuzzy
logic. Fuzzy logic tends to get used in a lot of autom atic focusing. (Those of you
reading this who are intim ately fam iliar with analog com puters and fuzzy logic, please
allow m e som e literary freedom here. Conceptually, they are sim ilar as a car and truck
are sim ilar. W e dont want to go too far down a bunny hole at this point.)
There are still som e analog com puters around, thought not m any. I dont
rem em ber the exact problem s they were the best at solving, but there is/was a niche
of software development which could use no other form of com puter. I have a nagging
thought in the back of m y m ind that stellar drift calculations were am ong 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 exam ple of analog
technology. When you were in a bad spot you could still m ake out pieces of what the
other person said even with all of the static. With m odern digital cell phones you
sim ply get a dropped call. Analog keeps going as long as there is any degree of truth;
binary stack dum ps. 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 system s back in the m id- tolate 80s. Truck loads of dollars w ere poured into com panies claim ing 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
m arket correction when none of these start-ups bore the tasty fruit investors were
looking to savor. Financially, it was not as horrific as the DO T COM flam e out, and
it did not have quite as m any crim inals 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 m uch stopped teaching it and IT started a downward spiral.
Logic taken too far gives you problem s like the AI investm ent debacle. What the
industry failed to realize is that logic, like cholesterol, m ust exist. There is good logic
and bad logic just like there is good and bad cholesterol.
The short answer is that logic is the m ost fundam ental of IT tools. Logic is what
allows you to get from input to output, no m atter what. Logic is the fram ework upon
which every com puter application is developed, even the object-oriented applications.
I.3 Prerequisites for This Book

This book only requires that you have som e interest in com puters and software
development. It will help if you have poked around with som e software development
tools or attem pted som e fundam ental program m ing on your own. By fundam ental
Im not talking about som e GU I 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 colum ns
of asterisks from 10 down to one so they looked like a crude bar graph. If that last
problem sounds horribly sim ple, try doing it w ithout having had a logic class. Try
doing it in under an hour. If you feel like adding insult to injury, try printing num bers
going dow n 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 com puters or software
developm ent. W e wont be writing any programs, only m apping out their logic, so you
do not even need a com puter. You m ight want to surf the W eb or visit an office supply
shop and see if you can find a flowcharting tem plate. This is a little green plastic
thing with different shaped holes cut in it. You use it and a pencil to draw a flow chart
on paper.
Introduction
I-5
I.4 Approach of This Book

M ost books on program m ing 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 problem s 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 m y approach.
I will cover the boring and dry com ponents of flowcharting and dabble a little with
pseudocode. From there we will m ove forward to som e of the standard program m ing
situations. This will let you actually see logic in action. It will also allow som e
im ages to sink into your brains. From there we will m ove forward into the general
approach of application design.
This may be a book whose later chapters you wish to read tw o or three tim es,
especially if you are new to IT. Nothing you do in your career w ill save you m ore tim e
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 com pleted
those in the first m onth. The entire rest of the sem ester 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. Adm ittedly, 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
som eone reading this book will do that in the end. W hat I do have is nearly two
decades of software developm ent experience to draw on when creating problem s for
you. There will be no choice but to start you out with som e 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
program m ing 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-m inded and far-reaching concepts
of application and systems analysis. There are an awful lot of other diagrams and
specification refinem ent m ethods. 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 com m on sense approach, naturally extending
program logic to application logic to system s design logic.
I-6
Introduction
I.5 W ho Should Read This Book?

Anyone who has even the slightest interest in softw are developm ent or needs to
m anage the software developm ent process should read this book. If you are
contem plating a career in software developm ent, 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 m ost fundam ental concepts of the software developm ent process
is critical to success in either of those career paths.
I.6 W hy is Flow charting and Pseudocoding Shunned?

Ill be honest. I havent drawn a program flowchart in nearly two decades. The
only tim e I write what could be called pseudocode for a m odule is when I have either
a really big chunk to chew or Im w riting a bid for approval. Notice that I specifically
stated program flowchart and pseudocode for a m odule. The devil is in the details.
W hen doing application or system s 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 hum an m ind was not
m eant to rem ain stretched around designs of that m agnitude for prolonged periods of
tim e. Normally, projects of that size take six m onths to a year before they even get
close to a testing stage. You need really good diagram s to remember what it was you
intended to do six m onths ago so you can set up useful test conditions.
As you progress in the field if IT, you w ill begin to understand why com panies w ill
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 m anagem ent could understand it. It took two
sheets of that paper six feet in length taped on the long edge to contain the diagram .
W hen it was scaled down to print on regular letter size paper on a norm al ink jet it
took close to a dozen sheets of paper taped edge to edge, and that w as using fonts no
larger than six points inside of the sym bols. You couldnt read it if it was m ore than
a foot from your eyes.
Program flow charting has been shunned because it is a lot of work. A flow chart
is only good before you write your first line of code. Once you start testing, you realize
there are problem s w ith your design and start m aking changes to the program . The
flowchart never gets updated. Bad docum entation is worse than no docum entation at
all because it leads people in the wrong direction. In the early 80s m any 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 sim pler. You could w rite it w ith any text editor or word processor.
In m any ways it was much like COBOL. Som e shops used to write pseudocode with
such detail that you could alm ost put a period at the end of each statem ent and get it
to com pile. This level of pseudocode was im possible to m aintain 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 tem plate that calls it a program
specification.
In days of old, a new program m er would be given a program specification from a
system s 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 statem ent. The m ost com plex system s 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
com pany and becom e stable. The reason you end up w orking on them is they look so
sim ple and innocent being only a few lines on a napkin.
Once a program m er received a specification for a new program , they would sit
dow n with pencil and paper draw ing out a very detailed flow chart. This flow chart
would docum ent 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 com pletely 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 m ore detail. This statem ent was
designed to tick you off for a day or two until the analyst had tim e for you. It really
didnt have m uch to do with what you had done. How do I know this? I was once one
of those flow chart drawing program m ers who got a flow chart rejected with that exact
phrase. A w eek later I submitted that exact same flowchart and it was accepted.
During that week I did flowcharts for the other analysts because they had tim e to chat
with m e.
Developers who paid their dues got to be program m er analysts. These w ere the
cherished job titles. Once you becam e a program m er analyst you never had to draw
another program flowchart. You got to code straight from the specification. W hen 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 m ore detail.
The result was that everyone wanted to be a program m er analyst. Everyone
wanted to just throw code at a problem and see what sticks. That was the fun job in
IT. Som e geeks prided them selves on how close to the m etal they could code. Even if
the shop had chosen BASIC or COBOL, they would find a w ay to toss in som e
Assem bler code just to prove how m uch of a geek they were. The fact that the
Assem bler code could never port to a new m achine, even in the sam e fam ily of
com puters, never stopped the geek of geeks from throwing it into the application.
I-8
Introduction
During your stint as a program m er analyst, you would get to cut your teeth writing
program specifications. Because you werent a system s analyst, your specification
could never be three lines on a napkin. N ormally 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 system s analyst before it would be assigned to a
program m er.
Life would then take an ugly turn for you. After one to five years as a program m er
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 program m er m anagem ent. While you would
toggle between writing system s specifications and application specifications, you would
never really do system s design. The task of system s design fell to the system s analyst.
W hen it cam e to bidding on contracts or very large applications, they w ould 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 com m and script.
M ost program m ers went into IT not only for the m oney, but because they really
liked the idea of coding up solutions to problem s. Once they got to the skill level of
program m er analyst, m ost would change jobs. Indeed, the average length of stay when
I was at that level was two years. Developers who loved to program sim ply didnt want
to give it up. The only way to avoid it was to leave the company.
Never let it be said that m arketing wont sell you a product that will kill you.
Along cam e case tools followed by pick and drag code generators. They would m arket
these products claim ing great leaps in productivity. The tools would have an interface
so appealing that even an M BA could generate the sam ple contact m anager program
in under half an hour. That poisoned apple sure tasted sweet to upper m anagem ent.
They threw tractor trailers full of m oney at the vendors of those products. Once PCs
with graphical desktops cam e out, an even bigger slew of visual type tools flooded the
m arket. Every one of them prom ised to make programm ers m ore productive. Every
one of them cost the industry m ore than will ever truly be known.
The argum ent was m ade on college cam puses that students would never have to
flowchart in real life, so why m ake them do it now? Grading those flowcharts certainly
took a lot of tim e. Drawing flowcharts w as a lot of work. It was agreed that flowcharts
would be dropped.
Because pseudocoding was taught in the sam e 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 W hy m ake them do it now? Had anyone answered that
question, it wouldnt have been dropped. Specification writing w ould 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 hom e. Nobody wanted to spend their
evenings with a table full of eraser crum bs, w hich is pretty much what a class
requiring flowcharting m ade of their evenings.
Flowcharting is shunned
training a developer who was
expected colleges to do that.
elim inate the need, or so they
because m anagem ent didnt want to eat the cost of

only going to spend two years at their company. They
When colleges failed, they threw m oney at tools to
thought.
Flow charting is shunned because this is a Visa/M asterCard 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
dow n form at the m uch 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 m onths are bad because you
arent any good at logic then. You understand som e 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 m odule or program problem . You would find yourself looking forward to hearing
newer developers ask, H ow am I supposed to do this? Turning around with a sm ile
you would say It is accom plished 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 Flow charting and the Current State of IT

Adm ittedly, this section probably belongs in one of m y Rum inations chapters, but
it fits here. There are few uglier tasks in the world of IT than being asked to draw a
flowchart. W hile it m ay take you m onths to track down a bug in a particularly nasty
piece of code, there is an im m ense sense of accom plishment that follows fixing it and
pointing the fix out to all of those program m ers 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 m ental training tool that m ust be endured. There is no other tool
that will condition your m ind 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 tim e to actually
review your flow chart and critique it. I can give you the fundam ental exam ples. There
was a m ethod 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 m arket. We are not talking about the total body count here, just the
percentage of that body count that actually has em ployable skills. Most of those
developers went straight into coding at shops without any mentor. During the ga-ga
days of m assive IT growth, shops that were either low paying or just true Hell holes
to w ork at had turn over rates that exceeded 100%. Some shops today are Hell holes
which find them selves in the sam e situation. W hile the developers w ho never learned
logic or flowcharting becam e better at the syntax of the language, they found
them selves failing m iserably once they were prom oted higher in the com pany.
System s analysts have been m oved into infrastructure roles and analysts are now
doing everything the system s analysts used to do as far as software design. I am of
course talking about shops that still have analysts. M ost have m ade that a task of the
IT department m anager.
The reality is that m ost 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 com petent and
knowledgeable about the business, hasnt focused on logic. They have focused on
enhancem ents 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.
W e, as an industry, are already seeing the fallout from this. Skilled coders are
being forced into m anagem ent roles w here every new functionality request becom es
an enhancem ent to the existing system rather than a new system design. System s,
which were originally designed to do only a few things really well, have now evolved
into a m onster perform ing 20 to 30 completely unrelated tasks. Some companies have
already im ploded because they were unable to respond to new inform ation 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, com pletely
skipping the coding portion of this industry. Com panies are playing a gam e 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 m ust then be
hidden, both publicly and in the books. What is m issing from their m ix is logic. The
coders they are hiring for $10/day havent been skilled in logic. The highly skilled
program m ers 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, stum ble 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 w hat had to be done to m ake it work. The project succeeded.
W hat happens now is upper m anagem ent issues a one line spec on the back of a
napkin. The analyst issues a 12 or fewer page design docum ent that was always good
enough before. The coders who havent got a clue about logic hack som ething together
and deliver it. Then everybody stands around pointing fingers while eyeing the black
sm oking 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 m yself. They should be appearing or have appeared in the
m arketplace by the tim e this book is published. You need to read these two books in
order as they build upon each other. The Minim um You Need to Know to Be an
OpenVM S Application Developer ISBN 0-9770866-0-7. The Minimum You Need to
Know About Java on OpenVM S Volum e 1" ISBN 0-9770866-1-5. Being the author, m y
opinion of them is somewhat skewed.
I-12
Introduction
Page left blank intentionally.
Chapter 1
Basics of Flowcharting
1.1 Flow charting Sym bols
W hen you are drawing program or function-level flowcharts, there are only a
handful of sym bols you need to concern yourself with. As you m ove onto application
and system flow diagram s, you encounter additional sym bols. It seem s each new tool
for laying out system flow diagram s adds a few sym bols or changes the m eaning of
them . Unless you stick to universal basics, system flow diagram s becom e very difficult
for anyone w ho is not a techno geek to follow. The goal of a flowchart is as m uch to let
the end user or custom er see how things will work as the developer and IT types to
envision a solution. Som e of the tools on the m arket lose sight of that. Be careful
when choosing program s to draw flowcharts for you.
Start/End
Term inator
Calculation or
Assignm ent
Hello
W orld!
Screen
Output
Report
Hard copy
output
Keyboard
M anual Input
Do_things
do_som ething
Internal
Predefined
Process
External
Predefined
Process
?
Decision
Connector
IO
B1
IO
Operation
Off Page
Connector
Collate
1-2
Chapter 1 - Basics of Flowcharting
Connect
Drive
Sort
Punched
Card
Extract
M erge
M anual
Operation
Punched Tape
A good m any of these sym bols you will never use. There are even m ore sym bols
that I sim ply didnt provide. In part I didnt provide them because they are not built
into W ordPerfect. The other part is quite sim ply that they dont com e up that often at
the program or application level.
The last two sym bols probably have som e of you laughing and asking if I can still
wear underwear or now need Depends. You have to rem em ber that flow charting
started when developers had to work close to the bare m etal. M any of us
program m ed in Assem bler. This was as close as you could get to the m achine
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 m any cases
w e didnt even have full-blow n operating system s. There were independent card
reader subsystem s, paper tape subsystem s and, if your com pany had oceans of m oney
to burn, a m agnetic drum . W hen you flow charted a program , you had to flow chart
the entire execution. Hence, we have the M anual Operation sym bol where you would
instruct the com puter 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. M em ory w asnt called RAM back then, it was called core. The reason is
it actually was a m agnetic core. It wasnt until m uch later that RAM cam e along,
followed by DRAM and a host of other types of RAM .
1-3
Here is an odd little tidbit for you. Any idea what the ticker tape was in a ticker
tape parade? It had tw o sources. The first source was the brokers and stock
exchanges. A paper tape device would print bid, ask and last sale for stock sym bols as
transactions happened. It wasnt printing like you would think of today. Every tim e
it printed it would m ake a ticking noise. This lead the industry to call the m inim um
price m ovem ent for a stock the tick size. Our second source of ticker tape was
abandoned paper tape from com puter rooms. Because the financial m arkets were som e
of the first businesses to use com puters outside of the m ilitary, this m ade sense. N ow,
when people hold a ticker tape parade, they have to buy confetti.
As subsystem s becam e better and better, they began to get standardized. The
standard groupings of these subsystem s cam e to be called operating system s.
Computer m em ory 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 M EG of m em ory installable. That is correct, words. Bytes
are 8 bits and words are 2 bytes. Today, m ost system s m easure RAM as som e grouping
of bytes, so in todays terms it would be 128K. In todays world, com pilers from
M icrosoft can barely create a program that prints Hello W ord! to the screen using less
than 128K, but back then we ran 30 to 64 users on a m achine with that m uch.
Operating system s began providing utilities that program m ers could use when
writing program s and/or applications. The m ost used of these utilities was the
SORT/M ERGE utility. Every real operating system provides this utility. The Sort,
Extract and M erge sym bols allowed us to show in our flowcharts that we planned on
using this utility.
The really old-tim ers would have a set of cards for input. They would indicate a
M anual Operation for the com puter operators to load the cards into the stand-alone
Card Sorter and set the switches a certain way. Som e tim e later they would com e back
and the cards would be sorted. There would be another m anual operation for the
operator to load the cards into one or m ore 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 m erge
for you by the sim ple virtue of sorting the entire bundle.
Disk drives turned Sort, Extract and Merge into a software-oriented process.
Oddly enough, the Extract feature becam e the front-end process for Sort. As
operating system sort utilities provided m ore and m ore functionality, they cam e with
various m ethods for creating either sort specification files or sort specification
param eters. Both sets allow ed 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 num ber, last nam e, etc.), you were allowed to add som e sort of selection
qualifier for that key. The sort utility created a tem porary file with the records you
selected, then it sorted those. It didnt take long for people to figure out that if the
tem porary file nam e could be specified and Sort could be m ade to stop after creating
it, then you just didnt need to write extract program s.
1-4
Collate is an odd little sym bol. As I recall, it started as a m anual operation for
operators to organize bundles of cards to be broken up between m ultiple card readers
(too m any for a single card reader). Then it m orphed into being used for organizing
reports that were printed on different printers. The last I rem em ber it being used was
for the m assively expensive all-in-one copy-print m achines. This was way before your
sub $300 all-in-one copy-fax-print machines came out. We are talking about m assive
high speed printers that som etim es had copy functions built in. A collation device was
hung on it that could sort and store anyw here 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 m e explain the collate function a little bit m ore. Prior to printing system s that
could bundle their output directly into an envelope stuffer, it was im portant. If you
had a charge account with som eone, you wanted to be the only one who got your
statem ent. In the days of continuous form printing and hand collating, this wasnt
always the case. The collating device ensured that only your statem ent was on that
tray, assum ing the operator got the tray em pty before it had to be re-used by the
printer. The operator w ould either hand fold and stuff it or hand carry it to the
stuffing m achine.
As long as we are talking about odd com puter hardware and term s, let m e drop a
couple m ore on you: burster and decollator two of the noisiest m achines to ever find
their way into a com puter room. It wasnt good to handle all of this paper in a
com puter room , but the printers of the days needed the additional cooling found in the
com puter 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. W hen 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 com ing in.
M ore than one new bie com puter operator got to spend their afternoon turning a report
around after feeding it in the wrong way.
The decollator was probably m y favorite. These m achines were an OSH A
(Occupational Safety and Health Adm inistration) disaster waiting to happen. Many
things that got printed by com puters back then, and even to some degree today, needed
to be printed in m ultiple copies. Today, people buy elcheapo ink jet printers and just
print m ultiple copies, then hope for the best if they end up in court. What big business
did was print on m ulti-part form , norm ally som ew here between two- and five -part
form s. This m eant that the exact sam e pre-printed form occurred that m any tim es in
a single perforated section. Early on they came with carbon paper between each sheet
and later sim ply 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
1-5
catcher. I honestly think we avoided a lot of deaths in the IT industry by having the
fem ale operators run the decollator. It was a fair trade. They usually made the male
operators lose their hearing running the burster. Dress codes seem ed to always m ake
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 sam e 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 sym bol when writing to a report file and the screen
output sym bol when writing to the terminal. W hen accepting input from the user, you
use the m anual input sym bol.
The connector is usually a much sm aller circle than I have drawn here. I needed
to m ake it large enough to get the caption under it without a line break. Whenever you
have m ultiple 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.
W hen you are drawing a large flowchart, it is not uncom m on to find yourself on the
other side of the diagram needing to return. You can either create the worlds ugliest
m ultiply 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 sam e label where
you wish to return.
I used to flowchart on the back of continuous form . It was not uncom m on for m e
to have single m odule flowcharts that were seven pages long. W hen you had a lot of
things to do in a processing loop before you read your next record, there was sim ply no
other way to get back to your input statem ent.
External predefined process encom passes operating system s library, hom e
grown library and system service functions. In todays world it also indicates stored
procedures in a database engine. Ordinarily you just put the nam e of the procedure
in the box. When drawing by hand I would put the nam e in the sm all 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. M ost 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 program m ing shop, this either worked for you
or put you in a world of hurt.
1-6
Look back at the explanation for external predefined process. See that phrase
hom e grown library? That is where the hurt com es in. Som e program m ing
languages enforce m aking 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 program s. The hurt com es, not at the
tim e of creation, but later in life. As you write m ore program s and others learn about
your function/subroutine, it gets re-used. This m eans it gets placed in the hom e
grown library. Your program didnt change, but your flowchart is now out of date if
you are using the purist definition.
The decision sym bol has som e odd uses. The norm al 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 tem ptation to give it wings. Have one line com e out the bottom and
the other com e out a side. Using the side points for each condition only looks good in
very short exam ples. When drawing out larger logic diagram s, it paints you off the
page pretty fast.
I said it has som e odd uses. They arent really odd, they just look odd to those
unfam iliar with them . Most com puter languages today have what is known as a
sw itch, select or evaluate statem ent. The general explanation for these statem ents is
that you do different things depending on the value of one variable. The variable nam e
gets placed in the decision sym bol, then you draw a line w ith 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 exam ple later in this text.
O ur calculation/assignm ent box is pretty m uch what it sounds like. In it you
will find statem ents like SALES_TAX = N ET_SALES * TAX_RATE. Dont worry if you
dont understand those nam es, as understanding them isnt a big hurdle.
Term inator should be the m ost straight forward sym bol in flowcharting. It has
caused m ore heated discussions than any sym bol I know. You use one of these sym bols
to start your flowchart and another to end your flowchart. Shouldnt be a problem ,
right? Guess again. The problem s surface around what goes inside of the sym bols.
Some camps became quite religious about using EXIT when the module is standalone 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 som e equally divided
cam ps. Som e believed strongly that it should be RETURN RET_VAL where RET_VAL
was the nam e of the variable containing your return value. Others believed it should
just be RETURN and the docum entation for the function should stipulate the return
value. One camp believed it should be EXIT RET_VAL because whatever language
they were using for program m ing actually ended a function with that syntax. A sm all
group of FORTRAN program mers used to cham pion the idea of the ending sym bol
1-7
being left blank. This was because in FORTRAN you assigned the return value to the
function nam e and the code sim ply stopped.
Do you really want m e to go into the argum ents about the content of the starting
sym bol? W e are just going to use START for stand-alone m odules and ENTER for
callable routines. Som etim es I will slip and use START all of the tim e. I will use
STO P, EXIT, END or RETU RN as I see fit on the last terminal. Please forgive m e.
As I stated earlier, there are sym bols 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 sym bols are wont do you m uch good if you dont know how to use
them .
1.2 Linear Sequence

You will draw m any sm all 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 exam ple I chose to show you an
unexpected use of the IO sym bol. Before you can
read from a file, the file m ust be opened for input.
Back in the day, m any shops w ere adam ant about
seeing both the open and the close clearly defined in
the flowchart.
All we did with this exam ple 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 im portant you understand why I

phrased Read a unit of IO the way I did. Com puter
files can contain a wide variety and organization of
data.
In this exam ple I didnt include any
inform ation about the file type or organization. Som e
shops had a separate docum ent that contained that
inform ation. Others had you put it in the com m ents.
I have to start you somewhere, so this is where Im
starting you.
1-8
M y display input sym bol doesnt have any preceding sym bols that would convert
binary data to display form at. For the purposes of this discussion, you m ust assum e
that the input file has one line of readily displayable ASCII text. (If you dont know
what ASCII is, please take som e tim e and search the W eb 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
m ore keys on them . A key is one or m ore fields defined at file creation tim e to be
an index into the file. An index is used to quickly get to one or m ore 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 system s
require, som e just recom m end, that the first key defined for a file be a unique key. The
first key is also usually called the Prim ary K ey. Ordinarily, when you access a file
via its prim ary key, you want to get exactly one record. The record that m atches 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 sm all exam ple later in this book. The point Im trying to m ake right
now is to be very careful about how you phrase things with respect to file IO.
1-9
1.3 Top Checking Loop

You are looking at one of the m ost
im plem ented logic structures in IT, the top
checking loop. Every 3GL (Third Generation
Language), m ost Object Oriented and m any
4G Ls (Fourth Generation Language) provide
this very logic structure. M any provide it in a
single statement like a for or while loop.
Quite sim ply, you initialize a variable to
som e value. At the top of that loop you check
the value against som e condition. Norm ally
this is a know n m axim um , but it can also be a
know n m inim um . In our case, X m ust be less
than or equal to 10 to continue. Ten is our
known m axim um .
Inside of the loop there is always som e
quantity of logic that gets perform ed. From the
loop perspective what happens in there is of
little importance.
The one and only
requirem ent is that your loop counting variable
m ust be adjusted prior to returning to the top
of the loop. Because we are checking against a m axim um , we added one to the loop
counter. If you are working your way down to a m inim um , you would subtract a value
from the counter variable.
Let m e 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 w ould not let m e have the end term inal stuck out to the
right like that. They would m ake m e place it at the bottom of the page and connect m y
arrow to it. Som e people are quite picky about the placem ent of this term inal. Id
rather be picky about how m uch logic you learn.
Som e of you m ay be wondering how I created these flowchart im ages because they
are m uch sm aller and som ewhat different from the im ages I presented initially. The
first im ages cam e directly from W ordPerfect. To save space and speed things up I
purchased a copy of Flow Diagram s Software http://www.anydraw.com . I didnt do
a large quantity of analysis. There are a lot of sharew are products out there which
draw flowcharts. This product cost me around US $30.00 and let m e save flowcharts
as JPEG files to im port into W ordPerfect. Your instructors m ay m ake you draw things
by hand with a plastic tem plate. No great crim e there, I did it for two years. Back
then I think I spent $30.00 and got a good 0.05m m pencil. They had just com e out and
werent com m on enough to be cheap. (I told you, Im old!)
1-10
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 m ay be
preordained by your choice of im plem entation languages. To use this variation you
initialize a variable to a known value (TRUE, FALSE, 0, 1, etc.). The test in the
decision sym bol checks for an equality or inequality. You typically set the flag to
another value based on som e condition which may be triggered from outside resources.
Sometim es it becomes what is really a m iddle checking loop.
1-11
1.4 Middle Checking Loop
You will notice a sym bol you havent seen before in the image on the left. This is
the symbol that once m eant tape input. Many drawing program s, including the one
Im using, now use it to indicate sequential data.
Pay attention to the dashed lines running from the tape sym bol to the IO sym bols.
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 m andate you put the actual record nam e in the other IO sym bols. I
dont really like the file sym bol 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 sym bol, nam e of the file, organization of file, keys and m ethod
of access (read, write, update or delete). Each file w ould be given som e hokey little
code like #1, #2, #3, etc. Because the sym bols were sm all, w e w ould use the codes
inside of the symbols. When we were drawing flowcharts for BASIC program s the
1-12
num bers directly corresponded to the channel num bers we would use in the program s.
Take a close look at the above diagram . W here do I ever set EOF to TRU E? The
answer is I dont. The error handling w rapped into the IO operation is going to set that
value for us. You probably do not know enough about software developm ent to fully
understand that statem ent, so let m e explain. Every language Ive ever worked with
(higher in the food chain than Assem bler) provides som e m ethod of built in IO
exception trapping. Ive encountered people in the past w ho dem anded you show this
in the flowchart. Going to that level really is a bit m uch. COBOL has an AT EN D
clause on its read statem ent. BASIC tosses BASIC ERROR 11. C provides the feof()
function so you dont even declare the EO F variable we used in this diagram . Most
developers are smart enough to understand EOF m eans End of File. If you have m ore
than one file use som ething like EOF_nam e or EOF_#2.
Take a look at m y decision sym bol in this diagram . I didnt label the branches.
M ost instructors will slap you pretty hard for that. M any instructors want you to put
sim ply EOF in the decision sym bol 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 m ind, you will be able to code it when you move onto
programm ing.
W hen it com es to the m iddle checking loop, most academ ics w ill hiss, cluck their
tongues and call it bad design. Those people have never worked in the real world for
a living. A m iddle checking loop is forced on us by language lim itations 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 com plete sets of error handling. The first one is
executed only one tim e before entering the loop, and the last one is executed at the
very bottom of the loop. I have coded it both ways in m y 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 m ade it a purist bottom checking loop, we
would have to add one m ore IO sym bol after do som ething. Then we would have to
find a way to get the dashed line from the sequential data sym bol over to it, or we
would have to m ake an additional copy of the sequential data sym bol. Either way, a
little bitty loop would start to get m essy.
You are now beginning to understand why every program m er m ust cut their teeth
with flowcharting. W hile it is technically true that you wont physically draw a
program flow chart in the real world, you will draw little pieces in your m ind as you are
writing.
1-13
1.5 Bottom Checking Loop

I didnt perform any file IO in this exam ple to keep it
sim ple 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 m issing.
Careful readers will note that in m y previous exam ple,
I didnt handle the condition of a m issing file. Som e
instructors will m andate you handle those conditions, others
will allow you to assum e critical error checking is handled
by the actual program .
Critical error checking is the trapping and handling of
hard errors that norm ally wouldnt occur during program
run tim e. You must handle those errors from inside of your
program unless you consider letting the user see an ugly
stack dum p on the screen acceptable.
Some operating systems will give you what is called a
stack dum p when you dont handle a critical error or your
program has a logic bom b. Most of you have probably used
an operating system of feeble capabilities like W indows.
Putting it in terms you understand, it w ould be when you
see that lovely General Protection Fault displayed. When
the W indows developers them selves forget to handle critical
errors you end up with the Blue Screen of Death.
Flowcharting doesnt give us a good m ethod of drawing out critical error handling.
It is one of the m any argum ents used against the teaching of flowcharting. You must
be taught flow charting if you are to ever succeed in program m ing. What you learn
when you learn flowcharting is the logic to accom plish your task. Program m ers who
start with drag & drop com ponent tools never learn logic and tend to be of little use.
1-14
1.6 M ultiple Decisions

This chapter is now 14 pages in length and you have covered all of the core
fundam entals for program flow charting. These are the basic building blocks which
allow us to create phenom enal designs. The next few exam ples will give you some idea
about how to hook them together. Later in this book we will cover som e more involved
exam ples. Logic is the path you m ust take to get from point A to point B. These tools
are what you use to both build and see the path.
The first com bination you need to be
able to visualize is multiple decisions.
The term m ultiple decisions really refers
to nested decisions. From a m echanical
standpoint they are pretty easy to draw.
Once you take a look at the example
to the left, you will begin to see m y advice
about not giving decision sym bols 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 sm all you couldnt m ake
anything out.
Nested decisions cannot be avoided.
The logic of everyday life tends to throw
us into situations that require them .
W hat 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 m y little expression. W hen you get farther along in your IT
career, you will be asked by your em ployer to im plement something just as m essed 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 m anual task. That will pretty m uch point out they
never did a process flow diagram . From there the gopher will ride down the m ountain.
Nobody will want to draw the process flow diagram . Resist all efforts by them to put
the flowchart creation on your back. Eventually their m ost junior person w ill be
saddled w ith the task. Som e six to eight weeks later, after a bunch of m eetings, the
request will sim ply go aw ay. They will realize they have been idiots for a very long
tim e and will begin to look for a politically correct way out of the debacle.
1-15
Both flowcharting and com puter languages have had to deal with multiple
decisions for a very long period of tim e. M any m ethods have been created to handle
them in as sane a m anner as possible.
One such method is the
switch/select/evaluate/ON construct. I gave you m ultiple choices on the nam e because
you will get a different nam e depending on which program m ing language you end up
using. Som e languages, like BASIC, give you two implem entations. It provides both
an ON -GOTO statement and a SELECT-CASE statement. From the flowcharting
aspect, it is all pretty m uch the sam e.
W hen draw ing one of these
constructs, it is im portant to either
specifically include a default/else
branch or add a docum ent com m ent
as to w hy it wasnt provided. When
you use this structure, you can
replace m an y n ested decision
statem ents with one clean structure.
It is a very powerful tool.
Normally, logic is independent of
the programm ing language used.
Should you choose to use this tool,
you need to understand what
capabilities it has in the underlying
language. M ost every language will
let you check a single integer
v a r ia b le a g a in s t h a rd c o d e d
(constant) integer values.
Som e
languages will let you check string
variables, but others, like C/C++ will
not. Other languages, like BASIC
on the OpenVM S 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 m achine. W rite it down.
Once you progress to actual program m ing, you will be taught m ultiple languages at the
sam e tim e. When you go out into the real world you will support applications and
system s written in m ultiple 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 tim e that you cannot. Write this day down and what you w ere told.
1-16
Tape it to your bedroom m irror. Within two years you will suddenly be rem inded of
it, trust m e.
I really m ust belabor this point w ith an exam ple. 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 am ount. The interest rates change daily and are stored in a
file on the system . They will have the following groupings: A uto, sm all m ortgage,
m edium m ortgage, large m ortgage, jum bo m ortgage and national debt. The m axim um
value for each of these loan rates is stored on the record with the loan rate. The
variable nam es are given to you and will be globally accessible to your function.
How do you flowchart som ething like that? Here is where you have to know the
program m ing language you will be working with. The worst-case scenario is that you
have to brute force the function with nested decision sym bols. If you are lucky enough
to be working with BASIC, your function flowchart will look m uch like the one above.
The decision sym bol w ill contain LOAN_AM T. Instead of new you will have <=
Auto. Instead of good you will have <= sm all m ortgage. The default will not
have a test, but sim ply receive the rate for national debt. In each of the boxes you
will assign the corresponding rate to the return value. W hen working with a language
that doesnt allow ranges or dynam ic variables for the individual case clauses, your
flowchart will becom e m ore difficult.
1.7 Flow charting Sum m ary

Here, inside of 16 pages, you have covered the fundam entals of flowcharting. You
do not, by any m eans, understand how to create flowcharts. What you have been
show n is a ham m er, saw and drill; but you dont yet know how to build a house.
It used to be said that a flowchart was a tool for program design. W hen you are
learning how to program , this is true to a point. A m ore accurate statem ent would be
that a flowchart is a visual tool that allows you to learn how to program . Once you
learn how to program , you will still use a flowchart when you have a particularly nasty
problem to solve. There is no replacement. There are many visual program m ing
languages on the m arket. None of them teach developers how to program . None of
them let you design a solution from the ground up. The problem is they all claim to do
this. What they create are drag and drop idiots. You are reading this book so you can
becom e som ewhat more than an idiot.
Flowcharts com e in m any varieties. The two m ost comm on of these is the system
flowchart and the m uch maligned program flowchart. I have only shown you the
m ajority of the sym bols for program flowcharting. Later on you will see som e snippets
of system flowcharting. A thousand-page program flowchart usually am ounts to little
m ore than a single box on a system flow chart because those charts work from a much
higher level.
1-17
You cannot be a great software developer, nor even a good program m er 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.
W hen the flowchart you are looking at, or Heaven forbid, writing, ends up with dozens
of criss-crossed lines and branches that are im possible to follow , you begin to realize
this was a bad design. M any will try to say it is just a poorly drawn flowchart and in
som e cases that will be correct. But the m ajority of the tim e 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 m em orize symbols. You learn them by using them and the focus
of this book is to provide problem s for you and the instructor to solve during class.
These questions are designed to teach you that som e of the most important details
seem insignificant the first tim e you are exposed to them . W elcome to your first real
lesson in logic.
1.8 Exercises
1.
W hat is the m ain difference between a bottom checking loop and a top checking
loop? The answer has nothing to do with where the check is perform ed.
2.
Under what circum stance must you choose a bottom checking loop over a top
checking loop?
3.
On m ost of todays com puters, what is the size of a byte?
4.
W hat is another term for m ultiple decisions when they are dependant upon each
other?
5.
W hen drawing a decision sym bol, on which side does the loop back, return or
branch above line connect?
6.
W hat is a program flowchart?
7.
W hen would you use a m iddle checking loop?
8.
W hat is a decollator, and why was it used?
9.
Given a specification If a = 1 do_som ething, a = 2 do_something_else, a = 3

do_a_different_thing, any other value do nothing, w hich structure would you
draw?
10. W hen m ultiple lines need to enter a single sym bol, which sym bol should you use
to join them ?
1-18
Page left blank intentionally.
Chapter 2
Basics of Pseudocode
2.1 W hat is Pseudocode?
Pseudocode is basically a tersely worded English language description of the
algorithm s to be im plem ented later in a program m ing language. In days of old, you
were told not to use words specific to a program m ing language. W hile that is good
advice, m any of the words you need to use were im plemented as verbs by a large
num ber of 3G L program m ing languages. W ords like if, do-while and perform
have been implem ented in one fashion or another by m any of the languages you will
find yourself eventually programm ing in. As a consequence of this: Most pseudocode
looks a lot like COBOL code.
You will find pseudocode still in use at m any shops, but not as it was originally
intended. It now exists prim arily in sections of system s specifications. When an
analyst writes a specification for a new and large system , there will inevitably be
several areas w here tricky algorithm s or form ulas are needed. W ere this form ula
sim ply nam ed 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 form ula or
algorithm in detailed pseudocode either directly in the specification or as an appendix.
2.2 Rules of Pseudocode

There arent m any rules for pseudocode. Each statem ent m ust end w ith a period
just like in the COBOL program m ing language. You are expressly forbidden to use the
word GOTO in your pseudocode. Paragraph nam es go on the left m argin and the
logic they contain is indented. Pages need to be num bered. If you have many pages,
you need to generate a table of contents listing each paragraph nam e and the page it
is on. External routines are to be written in all upper case.
The phrase external routines is one of those phrases tossed about by people who
dont like ugly details. It is a phrase like fam ily values, which means som ething
different to everyone who hears it, yet m akes everyone believe they know what you are
talking about. In general it means pre-existing routines or program s either provided
by the operating system or previously developed by your shop. Therein lies the rub.
W hat happens when you are writing pseudocode for a com pletely new system
consisting of dozens of program s and functions? Each program will utilize som e or all
of the external functions you have written up, but which are not yet im plem ented. Do
they qualify as external? Most would say yes, but you need to iron this definition out
with whoever will be reviewing your pseudocode prior to writing.
2-2
Chapter 2 - Basics of Pseudocode
2.3 The W hy and W hen of Pseudocode

The why and when of pseudocode have the sam e answer. Once you have done
enough flowcharting to inherently understand the difference between good and bad
logic, you will m igrate to pseudocode. You cannot start learning to program and
becom e a great program m er, just like you cannot start program m ing by learning the
syntax of a language and jum ping into coding. Flow charting teaches you to visualize
the tools of logic you will need to get from Point A to Point B. Flowcharting also takes
a lot of tim e.
W hen you are first learning to flowchart, you will start over m any tim es. This is
neither right nor wrong, sim ply part of the learning process. After you have done a few
flowcharts, you will realize you dont have to start over as often. Pretty soon you will
realize you almost never use your eraser except to fix spelling errors. Once you get to
that point, you are ready for pseudocode. Your m ind has expanded enough to grasp
logic as a tool.
Pseudocode lets you wield that tool m ore quickly. While it is true that there are
software packages that let you create flowcharts, they can be m ore cum bersom e to use
and learn than just using a pencil, paper and plastic flowcharting template. Indeed,
m ost every developer educated through the m id-1980s used no m ore than that.
Pseudocode can be written with any word processor, even the free ones like
OpenOffice. You do, however, need one which will let you keep m ultiple docum ents
open for editing sim ultaneously. One docum ent contains the table of contents or list
of functions/paragraphs you have already written; another, the pseudocode you are
working on; and a third for the functions/paragraphs you have nam ed but not yet
im plemented. Hopefully you wont have to use a really crum m y word processor like
M icrosoft W ord. If you learn how to use tabbed sections correctly, Lotus W ord Pro is
one of the best word processors ever developed. A close second is W ord Perfect. If your
school only has Microsoft W ord, I hum bly suggest you go looking for a free word
processor to use.
2.4 How Do You Learn to W rite Pseudocode?

First, you learn to draw flowcharts. Not just the m echanics of connecting sym bols,
but how to visualize the logic. You learn what an algorithm is and the difference
between a function and a subroutine. You learn that a function is a sm all algorithm
that may use other algorithm s just like a subroutine. Then you can learn to write
pseudocode. You learn by doing and that is why this book focuses on in-class exercises.
Your instructor will guide you by letting you make your own mistakes, then helping
you correct them .
2-3
2.5 Linear Sequence

Our linear sequence exam ple from Chapter One would read as follows:
Linear_Sequence:
Open input file.
Read Input.
Display Input.
Close File.
W hile this exam ple is crude and has no earth-shattering consequences, it shows
you a lot. Other than the nam e, nothing here lets you see it is a linear sequence.
W hen we flowcharted a linear sequence you could tell by the connecting lines and
arrow heads that it did not loop. As I stated earlier, you have to learn to flow chart
before you can be effective with pseudocode.
2.6 Top Checking Loop

Redeveloping our top checking loop from Chapter O ne gives us a little m ore to talk
about.
Top_Checking_Loop:
Let x = 0.
While x <= 10
Display x.
Add 1 to x.
End while.
If you have done any program m ing prior to reading this book, you will notice that
m any of the words used in this little exam ple tend to be words from a language you
have worked w ith. D isplay is typically used when you are writing to the default
output device. In this day and age that is the screen a user is sitting at. This is the
exact same verb COBOL uses for the exact same task.
M ost every program ming language you work w ith will have som e form of the while
loop as well. Just be careful when seeing the verb while in your program m ing
language because it is not synonym ous w ith a top checking loop. You will see that in
our bottom checking exam ple.
2-4
The line Add 1 to x is also a COBOL syntax. As I said earlier, most of your
pseudocode will read like COBOL. It is not an accident. COBOL was developed in the
1970s to be an E nglish-like programm ing language. Pseudocode is an English-like
program description language. The two are going to overlap a lot.
2.7 Middle Checking Loop

The one thing you will learn by reading pseudocode for our m iddle checking loop
exam ple from Book One is that pseudocode doesnt give you a good m ethod for
describing som e of the realities you will face in the program m ing world. Indeed, the
m iddle checking loop is so frowned upon by the goto-less program m ing purists, that
they m ade it difficult to im plem ent in pseudocode.
Middle_checking_loop:
Set eof to false.
Open input file.
Loop_top:
Read a record.
If eof <> true
Perform do_something.
else
Close input file.
Exit program .
End if.
next loop_top.
You get forced into the m iddle checking loop by reality som e tim es. W ith som e
program m ing languages, you cannot call or test for end of file until you have performed
at least one read from the file. Sim ply having it open isnt good enough. Other
languages, like COBOL, com pletely hide the m iddle checking aspect by providing an
AT END clause on the read statem ent where you would put the logic to close the file
and exit the program . Purists m aintain that you shouldnt take into consideration the
im plem entation language when writing pseudocode. The reality is that program m ing
shops only support a limited number of languages and the program m ers tend to think
in term s of those languages.
2-5
2.8 Bottom Checking Loop

Bottom_checking_loop:
Let x = 0.
Do
Add 1 to x.
Display x.
while x <= 10.
The pseudocode for our exam ple from Chapter One is pretty straight forward. You
m ay notice throughout this book that I use set, let and assign interchangeably
when initializing variables. This is a com m on practice with pseudocode. W hen it
comes to actual im plementation, the language will dictate how you do this. Some have
very different m eanings for set and assign. Let is a keyword from the BASIC
program m ing language. M ost versions of BASIC either no longer support it or sim ply
skip over it. In the early days of program m ing, it helped students to read LET X = 0"
so the compilers forced this syntax. Later, com piler writers realized that the compiler
only cared about the X=0" part so the syntax was relaxed.
2.9 M ultiple Decisions

W hen showing you decisions im plem ented as nested if statem ents or conditions
for flowcharting, I was able to create an em pty flowchart to emphasize the point of not
giving your decision sym bols wings. Pseudocode doesnt allow for an easy example
of that because you have to have words for everything. The developer writing the
pseudocode is free to keep indenting if statem ents to their hearts content. If they
choose to use a text editor instead of a word processor to write their pseudocode, they
wont even be stopped by the right m argin wrapping function built into m ost word
processors. This is yet another reason you have to learn flow charting before you learn
pseudocode. It teaches you how to avoid nesting decisions too deeply.
Chapter One did give us a nice exam ple of the select-case logic tool. Here it is in
pseudocode.
2-6
Select_case_example:
Evaluate customer_type
W hen NEW
Display offer for new credit card.
Break.
W hen GO OD
Display offer for 10% discount.
Break.
W hen BIG
Offer gift.
Break.
W hen DELINQUENT
Send to m anager.
Break.
Default
Enter into sweepstakes.
End Evaluate.
I chose to use the evaluate-when com bination, but could have just as easily used
select-case or sw itch-case. The syntax for this logic structure didnt appear in
pseudocode until after it had appeared in several program m ing languages so in this
case, the languages defined the syntax for pseudocode.
Please take note of the break statem ent. When w riting this logic structure in
pseudocode, always use the break statem ent if you dont wish a program m er to allow
for execution from one case to fall through to the next. Som e languages, m ost notably
C, allow for cases to fall through each other. While that technique can be handy, it can
get you into a lot of trouble if the compiler optim ization decides to change the order of
the statem ents it generates. Let m e show you.
2-7
Select_case_example_with_fall_through:
Evaluate customer_type
W hen NEW
Display offer for new credit card.
Break.
W hen BIG
Offer gift.
W hen GO OD
Break.
W hen DELINQUENT
Send to m anager.
Break.
Default
Enter into sweepstakes.
End Evaluate.
Notice the subtle changes. We rem oved the duplicate logic to display a 10%
discount by m oving the when BIG condition above GOOD and allowing it to fall
through the GOOD condition. When drawing logic with a flowchart, you dont have
to worry about this kind of am biguity. The lines and arrows only go to one place and
it is the responsibility of the developer to im plem ent what is drawn. Words are open
to interpretation. If you leave out the break and really m ean for the cases to be
independent of each other, then you are at the m ercy of the program m er and the
program m ing language when it com es to im plem entation.
2.10 Pseudocode Followup

Pseudocode is a quick and powerful program specification tool. With its speed
com es a lot of opportunity for error. As was dem onstrated with the select-case
exam ple, assum ptions or sim ple om issions can have drastic results during
im plem entation. Once you get into the real world as a program m er, you will only use
pseudocode to work out intricate details of tough routines. In truth, if the problem is
really difficult, you will see seasoned developers reaching for pencil and paper to
actually flowchart that little section.
Pseudocode allows for assum ptions, flowcharting does not. W hen you becom e good
at flowcharting, you will be ready to write pseudocode. One of the biggest crim es that
occur w ith pseudocode is the om ission of detail. It is not uncomm on to see a statem ent
like Com pute Interest Rate in pseudocode without any hint or direction about how
to do it. Things like that are m uch m ore difficult to hide when som eone looks at a
flowchart.
2-8
2.11 Exercises
1.
In todays IT shops, how is pseudocode generally used?
2.
W hy should pseudocode be learned after flowcharting?
3.
W hat keyword or phrase is expressly forbidden when writing pseudocode?
4.
Given a variable which can have five different values and a different action
associated with each of those values, what logic structure would you use?
5.
W hat 3GL program m ing language w ill you find the pseudocode syntax m im icking
and why?
Chapter 3
Some Fundamental Data Types

3.1 Core Data Types
Core data types are those data types that are viewed as fundamental to life in IT.
They are the building blocks used to create m ost other data types. If you graduated
high school and have looked at the labels affixed to advertisem ents you receive in the
m ail, you are fam iliar with all of them . You just m ay not realize it. Let us start sim ple
and work our way forward.
Alm ost all com puter languages have what is called a character data type. This is
a data type which holds exactly one character. A character is one entity out of the
character encoding set used by the platform . There are m any character encoding sets.
The m ost com m on set is the ANSI (Am erican National Standards Institute) set called
ASCII (Am erican Standard Code for Inform ation Interchange). Many IBM m ainfram e
com puters use EBCDIC (Extended Binary Coded Decim al Interchange Code). An
encoding set gaining ground with the Java program m ing language is U nicode. Dont
delve too deeply into what these are until you have to. At som e point, m uch further
along in your career, you w ill encounter a situation where you have to transfer
character data from one set to another, but you are not at that point yet. There are
also tools that can be obtained to do the transform ation for you.
A character is a single value out of one of these sets. The character m ay or may not
be printable. Some character entries are left undefined in som e of these sets to allow
graphics developers and security people to put in their own m eanings. Basically, there
are printable characters, like the letters in a word or the num bers you see written,
control characters and printable control characters.
Printable control characters are the easiest to explain. Things like TAB, carriage
return, line feed, etc. They control the placem ent of characters when displaying or
printing.
The other control characters m ostly have to do w ith IO (Input Output) operations.
There is a bunch of them to handle com m unications via a serial connection or m odem .
Som e of you may still access the Internet via a dial-up connection so you have seen
som e of these characters in operation w hen you initiate your connection. The other
characters have to do with file operations, m ost notably EOF (End of File). This is a
m arker used by m any operating system s to indicate there is nothing more to be read
from a file.
3-2
Chapter 3 - Some Fundamental Data Types
You m ay never actually use all characters in a character set, but at one tim e they
all had a specific purpose. Most books covering the Assem bler language for your
platform will have a chart for the native character set and its values.
Num eric data types get interesting because there are m any and the nam es have
different meanings on different platform s. The m ost com m on type is the Integer data
type. When this value is signed, it can contain any whole num ber, positive or negative.
W hen it is unsigned, it can only contain zero and what are called the counting
num bers. It does not natively store any fractional am ounts.
Rem em ber all of the fun you had learning fractions back in school? W hen you
learned that 3/4 = 0.75 and you thought you could just use a calculator for everything,
then the instructor tossed out problem s using 1/3, which was an infinitely repeating
decim al on your calculator, and you couldnt get the sam e answer as the students who
actually worked the problem out by hand? Fractional values have several categories
of data types. Within those categories are m any physical data types. Every one of
these physical data types has a precision problem . In this case, precision refers to the
num ber of digits to the right of the decim al point that can be stored accurately. You
are not ready to go into a discussion on precision, nor will it happen in this book. You
do need to be aware of why som e of these data types wont work for your logic.
You will hear program m ing types toss around various generic nam es for these data
types: Float, Real, Single and D ouble. In m any languages, Float, Real and Single are
synonym s. Depending on how the code was com piled, they could all m ean Double. You
will also find a host of other data types designed to provide lim ited fractional
capabilities in a sm aller space, faster, but having m ore of a precision lim itation. Som e
nam es you will find used for these types is Zoned D ecim al, Packed Decim al and Scaled
Integer. Each one serves a purpose. Both Zoned Decim al and Scaled Integer are in
wide use even today. Packed decim al is used only by places w hich started using it in
the 1970s and usually those are IBM m ainfram e shops. That platform provided built
in OS and hardware support for Packed Decim al m ath, m aking the data type one of the
better choices on it.
As a general rule, the Float, Real and Single data types, depending on what
floating point standard is used, give you at m ost four digits of precision to the right of
the decim al place. While they store m any m ore, those are all subject to rounding
errors. Ive yet to see a Double im plem entation that didnt give you at least six digits
and som e give you eight. Hence the full nam e Double Precision and the original nam e
for Float/Real was Single Precision.
Each of these data types is a trade off between speed, storage space, precision and
m axim um value. To gain digits of precision to the right of the decim al place, you give
up m axim um value on the left. From a disk storage perspective, scaled integer tends
to be the m ost efficient. This is why you see m ost database products storing floating
point data in a scaled integer data type. Scaled integer data types can be brutal to do
3-3
m ultiplication and division w ith, hence, most database products convert the scaled
integer to som e form of float upon retreval.
3.2 Data Type Sizes

To understand a little m ore about precision, you need to understand a little about
data type sizes. Each data type has a predefined size when it is used by a
program m ing language. Each language can, and som etim es does, use a different size
from all others.
The smallest entity addressable on any com puter system I have w orked w ith is a
bit. Many languages let you access bits directly, but few let you declare variables one
bit in size. W hat they usually do is let you declare a data type of som e other type, then
nam e each of the bits as part of a structure. Bit fields can only have a value of On or
Off (0 or 1). They are quite useful as boolean variables that can only have True or
False (On or Off) states.
In todays world, m ost com puter system s will define som e data types to be one byte
in size. A byte is usually 8-bits on todays system s. This was not always the case. In
the old days of 4-bit computer systems, some bytes were only 4-bits w ide. W e are
already seeing a shift in m odern com puter languages towards making the smallest
addressable variable 16-bits. In the future, I expect that this fundam ental definition
will change to be at least 32-bits. Not because of any particular need from the
program m ing com m unity, but because the easiest m ethod of addressing larger
am ounts of m em ory is to increase the m inim um addressable size. The sam e num ber
of addresses can be used to address a m uch larger quantity of m emory.
M any program m ing languages im plem ent the character data type as a byte. This
m eets the needs of ASCII and EBCD IC coding sets. It does not m eet the needs of the
Unicode set, which requires a m inim um of 16-bits. Each character is stored as a binary
value, which is a subscript into the encoding table provided by either the program m ing
language or the operating system . (W e will talk about tables in a little bit.)
W hat seem s to be som ething of a standard these days is an Integer data type being
defined as 16-bits. A long version of this tends to be 32-bits and a quad version, 64bits. Translated, that is 2-bytes, 4-bytes and 8-bytes, respectively. Some languages
and databases let you declare a Tiny Int, which is only 1-byte in size. A Tiny Int
typically is used to store things like a m onth or a day from a date structure. (W e will
cover structures a little later in this chapter as w ell.)
Single precision floating point data types tend to be 4-bytes in size on m ost
platform s. The actual encoding m ethod used differs with each language and platform ,
but the size tends to be pretty consistent. Double precision floating point data types
3-4
tend to be 8-bytes in size. Once again, encoding schem as very.

All bets are off when it com es to Zoned Decim al, Packed Decim al and Scaled
Integer. Som e platform s and databases allow for a scaled integer to be a dynam ic
num ber of bytes in size. Packed decim al has a standard, but it isnt always followed.
Zoned decim al tends to be a varying num ber of bytes for the num ber of digits being
stored.
Ive been tossing around the Packed Decim al and Zoned Decim al term s, so perhaps
I should define it for you. For m ost of the com puters you work with, a byte is defined
as 8-bits. Half of that (4-bits) is called a nibble. Yes, people who come up w ith nam es
in the geek world like to have a little fun. They also like to double things. A byte is
two nibbles, a w ord is two bytes, a long is two words, etc. Because storage was very
expensive early on, com piler developers and language designers cam e up with
interesting ways to save space for num bers. They decided to start using the nibbles
differently.
Zoned D ecim al m ight have com e first. It makes sense if it did, but it doesnt
m atter. This was a m ethod of storing num eric data in character format, one character
for each digit. IBM had EBCDIC and the rest of us had ASCII. The num ber 789 was
F7 F8 F9 when stored in EBCDIC but 373839 when stored in ASCII. Both form ats
were directly printable and the CO BOL language provided libraries that allowed you
to do m ath with them . This language introduced us to the phrase assum ed decim al.
W hen you w ere declaring a Zoned Decim al variable in COBOL, it was declared
som ething like PIC 9(3) which translated to 3 Zoned Decim al digits. If you needed
decim al points for financial statem ents, things would get declared along the lines of
PIC 9(5)V99 where the V indicated the assum ed decim al. We say it was assum ed
because it was never stored. I should also point out that the leading letter for the last
digit had a m ethod to its m adness.
ASCII
EBCDIC
Unsigned
Signed Positive
Signed Negative
Positive Zero
Negative Zero
You have been reading an excerpt. Please visit

http://www.theminimumyouneedtoknow.com to learn more about the series
and to find out how to purchase books by this author.

The Minimum You Need To Know About Logic To Work in IT

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

The Minimum You Need To Know About Logic To Work in IT

Загружено:

Авторское право:

Доступные форматы

The Minimum You Need to Know

About Logic to Work in IT

Copyright 2007 by Roland Hughes

Source Code License

I.2 W hat is Logic?

I.3 Prerequisites for This Book

I.4 Approach of This Book

I.5 W ho Should Read This Book?

I.6 W hy is Flow charting and Pseudocoding Shunned?

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

because m anagem ent didnt want to eat the cost of

I.7 Flow charting and the Current State of IT

I.8 Additional Reading

Page left blank intentionally.

Chapter 1 - Basics of Flowcharting

Chapter 1 - Basics of Flowcharting

Chapter 1 - Basics of Flowcharting

Chapter 1 - Basics of Flowcharting

Chapter 1 - Basics of Flowcharting

Chapter 1 - Basics of Flowcharting

1.2 Linear Sequence

Open an input file

It is very im portant you understand why I

Chapter 1 - Basics of Flowcharting

Chapter 1 - Basics of Flowcharting

1.3 Top Checking Loop

Chapter 1 - Basics of Flowcharting

Chapter 1 - Basics of Flowcharting

1.4 Middle Checking Loop

Chapter 1 - Basics of Flowcharting

Chapter 1 - Basics of Flowcharting

1.5 Bottom Checking Loop

Chapter 1 - Basics of Flowcharting

1.6 M ultiple Decisions

Chapter 1 - Basics of Flowcharting

Chapter 1 - Basics of Flowcharting

1.7 Flow charting Sum m ary

Chapter 1 - Basics of Flowcharting

On m ost of todays com puters, what is the size of a byte?

W hat is a program flowchart?

W hen would you use a m iddle checking loop?

W hat is a decollator, and why was it used?

Given a specification If a = 1 do_som ething, a = 2 do_something_else, a = 3

Chapter 1 - Basics of Flowcharting

Page left blank intentionally.

2.2 Rules of Pseudocode

Chapter 2 - Basics of Pseudocode

2.3 The W hy and W hen of Pseudocode

2.4 How Do You Learn to W rite Pseudocode?

Chapter 2 - Basics of Pseudocode

2.5 Linear Sequence

2.6 Top Checking Loop

Chapter 2 - Basics of Pseudocode

2.7 Middle Checking Loop

Chapter 2 - Basics of Pseudocode

2.8 Bottom Checking Loop

2.9 M ultiple Decisions

Chapter 2 - Basics of Pseudocode

Chapter 2 - Basics of Pseudocode

2.10 Pseudocode Followup

Chapter 2 - Basics of Pseudocode

In todays IT shops, how is pseudocode generally used?

W hy should pseudocode be learned after flowcharting?