DOCSLIB.ORG

Design Information Recovery from Legacy System COBOL Source Code

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design Information Recovery from Legacy System COBOL Source Code Nova Southeastern University NSUWorks CEC Theses and Dissertations College of Engineering and Computing 1996 Design Information Recovery from Legacy System COBOL Source Code: Research on a Reverse Engineering Methodology Robert Lee Miller Nova Southeastern University, [email protected] This document is a product of extensive research conducted at the Nova Southeastern University College of Engineering and Computing. For more information on research and degree programs at the NSU College of Engineering and Computing, please click here. Follow this and additional works at: http://nsuworks.nova.edu/gscis_etd Part of the Computer Sciences Commons Share Feedback About This Item NSUWorks Citation Robert Lee Miller. 1996. Design Information Recovery from Legacy System COBOL Source Code: Research on a Reverse Engineering Methodology. Doctoral dissertation. Nova Southeastern University. Retrieved from NSUWorks, Graduate School of Computer and Information Sciences. (727) http://nsuworks.nova.edu/gscis_etd/727. This Dissertation is brought to you by the College of Engineering and Computing at NSUWorks. It has been accepted for inclusion in CEC Theses and Dissertations by an authorized administrator of NSUWorks. For more information, please contact [email protected]. Design Information Recovery from Legacy System COBOL Source Code: Research on a Reverse Engineering Methodology by Robert Lee Miller A Dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy School of Computer and Information Sciences Nova Southeastern University 1996 We hereby certify that this dissertation, submitted by Robert L. Miller, confonns to acceptable standards and is fully adequate in scope and quality to fulfill the dissertation requirements for the degree of Doctor of Philosophy. ~ J~ Date Chairperson of Dissertation Committee Jacques Levin, Ph.D. Dissertation Committee Member Dissertation Committee Member Approved: ~---..... Edward Lieblein, Ph.D. Date Dean, School of Computer and Infonnation Sciences School of Compeer and Infonnation Sciences Nova Southeastern University 1996 Certification Statement I hereby certify that this dissertation constitutes my own product and that the words or ideas of others, where used, are properly credited according to accepted standards for professional publications. An Abstract of a Dissertation Submitted to Nova Southeastern University in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy Design Information Recovery from Legacy System COBOL Source Code: Research on a Reverse Engineering Methodology by Robert L. Miller October 1996 Much of the software in the world today was developed from the mid-1960s to the mid- 1970s. This legacy software deteriorates as it is modified to satisfY new organizational requirements. Currently, legacy system maintenance requires more time than new system development. Eventually, legacy systems must be replaced. IdentifYing their functionality is a critical part of the replacement effort. Recovering functions from source code is difficult because the domain knowledge used to develop the system is not routinely retained. The source code is frequently the only reliable source of functional information. This dissertation describes functional process information recovery from COBOL source code in the military logistics system domain. The methodology was developed as an information processing application. Conceptual and logical models to convert source code to functional design information were created to define the process. A supporting data structure was also developed. The process reverse engineering methodology was manually applied to a test case to demonstrate feasibility, practicality, and usefulness. Metrics for predicting the time required were developed and analyzed based on the results of the test case. The methodology was found to be effective in recovering functional process information from source code. A prototype program information database was developed and implemented to aid in data collection and manipulation; it also supported the process of preparing program structure models. Recommendations for further research include applying the methodology. to a larger test case to validate findings and extending it to include a comparable data reverse engineering procedure. ACKNOWLEDGMENTS Completing a doctoral dissertation is a long and arduous process that requires extraordinary dedication, commitment, and perseverance. Throughout this effort, support was provided by a group of people to whom lowe a deep debt of gratitude. For without their support, this research project would have never been completed. I am indebted to my dissertation advisor, Dr. Junping Sun, who offered critical encouragement, advice, and criticism. I also wish to thank Dr. Jacques Levin and Dr. Marlyn Kemper Littman, dissertation committee members. They guided me in the transformation of a fuzzy concept into a worthwhile research project. I am grateful to the staff and faculty of the Nova Southeastern University School of Computer and Information Science. They are, without exception, dedicated to assisting the doctoral student. A co-worker, JoAnn Gody) Morley listened patiently and provided valuable ideas and suggestions during preliminary applications of the concepts upon which this research is based. Thanks for your confidence, jody. Many thanks to Heather Pierce, also a co-worker, who read the early drafts and made sure they were written in English. Her help was invaluable in keeping my writing concise and to the point. Finally, my deepest gratitude and appreciation to my wife, Fumiko, for her understanding, tolerance, and support. R.L.M. Table of Contents Abstract iii Acknowledgments IV Table of Contents V List of Tables xiii List of Figures xv Chapter L Introduction 1 Statement of the Problem 1 Barriers and Issues 2 Barriers to Reverse Engineering 2 Issues in Reverse Engineering 3 Importance of the Topic 4 Significance of the Research 7 Definition of Terms 8 Brief History of Reverse Engineering 9 Objectives of the Research 10 Scope of the Research 11 Research Questions Investigated 12 Research Methodology 13 Phase I: Approach Selection 13 Phase II: Methodology Development 13 Phase III: Case Problem Selection 14 Phase IV: Methodology Application 14 Phase V: Methodology Assessment 15 Limitations and Delimitations of the Research 15 Limitations of the Research 15 Delimitations of the Research 16 Contributions of the Research 17 Theoretical Contribution 17 Managerial Contribution 17 Criteria for Success 19 Documented Reverse Engineering Methodology 20 Validated Methodology 20 Program Information Database Conceptual and Logical Data Models 21 Work Load Estimation Metrics 21 Summary 21 n. Review of the Literature 23 Introduction 23 Programming Languages 25 Programming Language Syntax 26 Programming Language Semantics 27 Programming Language Components 28 Job Control Language (JCL) 29 The COBOL Language 30 COBOL ffistory 31 COBOL Structure 32 Nature of COBOL 41 COBOL Disadvantages 43 COBOL Advantages 49 Program Understanding 49 The Meaning of Program Understanding 52 Software Psychology 53 Factors Affecting Program Understanding 55 Domains and Program Understanding 59 Approaches to Program Understanding 61 The Need for Reverse Engineering 63 Legacy Systems 64 Software Aging 66 Business Changes 68 Business Process Reengineering 68 Client/Server Technology 69 Object-Oriented Technology 70 Software Maintenance 70 Reverse Engineering Economics 71 Reverse Engineering 74 Reverse Engineering Objectives 82 The Basis for Reverse Engineering 83 Reverse Engineering Problems 84 Design RecoverylInverse Engineering 90 Existing Reverse Engineering Procedures 91 Software Physical Structure 97 Knowledge-based Program Understanding Tools 98 Transformation Tools 99 Program Plans 99 Data Flow Diagrams 100 Functional Abstraction Tools 100 Computer Assisted Reverse Engineering (CARE) Tools 101 Summary 104 m. Methodology 109 Research Methods Employed 110 Specific Procedures Employed 111 Description of Phase 1 - Reverse Engineering Approach Selection 111 Description of Phase 2 - Reverse Engineering Methodology Development 113 Description of Phase 3 - Case Study Subject Selection 114 Description of Phase 4 - Reverse Engineering Methodology Application 114 Description of Phase 5 - Methodology Assessment 115 Execute the Reverse Engineering Synthesis Plan 115 Problem Definition 116 The Operational Environment 116 Operational Problems 117 COBOL Program Environment 118 A Forward Engineering Model 120 Essential Points in the Forward Engineering Model 121 Information Loss in Forward Engineering 128 A Model of the Reverse Engineering Process 131 Differences in Forward and Reverse Engineering 13 1 Problems Associated with Reverse Engineering 134 A Formal Method of Reverse Engineering - Clean-SpecifY-SimplifY 140 A Structural Approach to Reverse Engineering - Program Schematics 143 A Program Understanding Approach to Reverse Engineering - DESIRE 151 A Data-Oriented Reverse Engineering Technique - Component Extraction 155 A Data Repository Approach to Reverse Engineering - System Description Database 160 Reverse Engineering Approach for Air Force Logistics Systems 164 A Model On-line Program 166 A Model Batch Program 169 A Model Fourth Generation Language (4GL) Program 171 Reverse Engineering Process Output Products 173 Developing the Reverse Engineering Methodology 178 Purpose 178 Scope 178 Strategy 179 Goals 183 The Conceptual Process Model 184 The Conceptual Data Model
Load more

Recommended publications
  • ASSESSING the MAINTAINABILITY of C++ SOURCE CODE by MARIUS SUNDBAKKEN a Thesis Submitted in Partial Fulfillment of the Requireme
    ASSESSING THE MAINTAINABILITY OF C++ SOURCE CODE By MARIUS SUNDBAKKEN A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science WASHINGTON STATE UNIVERSITY School of Electrical Engineering and Computer Science DECEMBER 2001 To the Faculty of Washington State University: The members of the Committee appointed to examine the thesis of MARIUS SUNDBAKKEN find it satisfactory and recommend that it be accepted. Chair ii ASSESSING THE MAINTAINABILITY OF C++ SOURCE CODE Abstract by Marius Sundbakken, M.S. Washington State University December 2001 Chair: David Bakken Maintenance refers to the modifications made to software systems after their first release. It is not possible to develop a significant software system that does not need maintenance because change, and hence maintenance, is an inherent characteristic of software systems. It has been estimated that it costs 80% more to maintain software than to develop it. Clearly, maintenance is the major expense in the lifetime of a software product. Predicting the maintenance effort is therefore vital for cost-effective design and development. Automated techniques that can quantify the maintainability of object- oriented designs would be very useful. Models based on metrics for object-oriented source code are necessary to assess software quality and predict engineering effort. This thesis will look at C++, one of the most widely used object-oriented programming languages in academia and industry today. Metrics based models that assess the maintainability of the source code using object-oriented software metrics are developed. iii Table of Contents 1. Introduction .................................................................................................................1 1.1. Maintenance and Maintainability.......................................................................
    [Show full text]
  • C++ Programming: Program Design Including Data Structures, Fifth Edition
    C++ Programming: From Problem Analysis to Program Design, Fifth Edition Chapter 5: Control Structures II (Repetition) Objectives In this chapter, you will: • Learn about repetition (looping) control structures • Explore how to construct and use count- controlled, sentinel-controlled, flag- controlled, and EOF-controlled repetition structures • Examine break and continue statements • Discover how to form and use nested control structures C++ Programming: From Problem Analysis to Program Design, Fifth Edition 2 Objectives (cont'd.) • Learn how to avoid bugs by avoiding patches • Learn how to debug loops C++ Programming: From Problem Analysis to Program Design, Fifth Edition 3 Why Is Repetition Needed? • Repetition allows you to efficiently use variables • Can input, add, and average multiple numbers using a limited number of variables • For example, to add five numbers: – Declare a variable for each number, input the numbers and add the variables together – Create a loop that reads a number into a variable and adds it to a variable that contains the sum of the numbers C++ Programming: From Problem Analysis to Program Design, Fifth Edition 4 while Looping (Repetition) Structure • The general form of the while statement is: while is a reserved word • Statement can be simple or compound • Expression acts as a decision maker and is usually a logical expression • Statement is called the body of the loop • The parentheses are part of the syntax C++ Programming: From Problem Analysis to Program Design, Fifth Edition 5 while Looping (Repetition)
    [Show full text]
  • Compiler Construction Assignment 3 – Spring 2018
    Compiler Construction Assignment 3 { Spring 2018 Robert van Engelen µc for the JVM µc (micro-C) is a small C-inspired programming language. In this assignment we will implement a compiler in C++ for µc. The compiler compiles µc programs to java class files for execution with the Java virtual machine. To implement the compiler, we can reuse the same concepts in the code-generation parts that were done in programming assignment 1 and reuse parts of the lexical analyzer you implemented in programming assignment 2. We will implement a new parser based on Yacc/Bison. This new parser utilizes translation schemes defined in Yacc grammars to emit Java bytecode. In the next programming assignment (the last assignment following this assignment) we will further extend the capabilities of our µc compiler by adding static semantics such as data types, apply type checking, and implement scoping rules for functions and blocks. Download Download the Pr3.zip file from http://www.cs.fsu.edu/~engelen/courses/COP5621/Pr3.zip. After unzipping you will get the following files Makefile A makefile bytecode.c The bytecode emitter (same as Pr1) bytecode.h The bytecode definitions (same as Pr1) error.c Error reporter global.h Global definitions init.c Symbol table initialization javaclass.c Java class file operations (same as Pr1) javaclass.h Java class file definitions (same as Pr1) mycc.l *) Lex specification mycc.y *) Yacc specification and main program symbol.c *) Symbol table operations test#.uc A number of µc test programs The files marked ∗) are incomplete. For this assignment you are required to complete these files.
    [Show full text]
  • Software Maintenance Maintenance Is Inevitable Types of Maintenance
    SoftWindows 8/18/2003 Software Maintenance • Managing the processes of system change Reverse Engineering (Software Maintenance & Reengineering) © SERG Maintenance is Inevitable • The system requirements are likely to change while the system is being developed because the environment is changing. • When a system is installed in an environment it changes that environment and therefore changes the system requirements. Reverse Engineering (Software Maintenance & Reengineering) © SERG Types of Maintenance • Perfective maintenance – Changing a system to make it meet its requirements more effectively. • Adaptive maintenance – Changing a system to meet new requirements. • Corrective maintenance – Changing a system to correct deficiencies in the way meets its requirements. Reverse Engineering (Software Maintenance & Reengineering) © SERG Distributed Objects 1 SoftWindows 8/18/2003 Distribution of Maintenance Effort Corrective maintenance (17%) Adaptive maintenance Perfective (18%) maintenance (65%) Reverse Engineering (Software Maintenance & Reengineering) © SERG Evolving Systems • It is usually more expensive to add functionality after a system has been developed rather than design this into the system: – Maintenance staff are often inexperienced and unfamiliar with the application domain. – Programs may be poorly structured and hard to understand. – Changes may introduce new faults as the complexity of the system makes impact assessment difficult. – The structure may be degraded due to continual change. – There may be no documentation available to describe the program. Reverse Engineering (Software Maintenance & Reengineering) © SERG The Maintenance Process • Maintenance is triggered by change requests from customers or marketing requirements. • Changes are normally batched and implemented in a new release of the system. • Programs sometimes need to be repaired without a complete process iteration but this is dangerous as it leads to documentation and programs getting out of step.
    [Show full text]
  • System Software Maintenance and Support 24X7
    SYSTEM SOFTWARE MAINTENANCE AND SUPPORT SERVICES - PREMIUM These Premium System Software Maintenance and Support Service terms and conditions (“Terms and Conditions”) apply to any quote, order, order acknowledgment, and invoice, and any sale or provision of Premium System Software Maintenance and Support Services as defined herein provided to Customer by Viavi Solutions Inc. (“Viavi”), in addition to Viavi’s General Terms (“General Terms”) and/or Software License Terms, which are incorporated by reference herein and are either attached hereto, available at www.viavisolutions.com/terms or available upon request. k) Severity Level means classification of a problem determined by Viavi personnel 1. PURPOSE AND SCOPE based upon the Customer’s assessment of business impact. The three (3) Severity Levels that apply to the Services are as follows: These Terms and Conditions describe the Services that Viavi will provide to, and perform for, Customer. These Terms and Conditions apply to Services for standard Software, as 1) Problem Report – Critical means conditions that severely affect the defined herein, and are limited to the System configuration specified in a Statement of primary functionality of the System and because of the business impact to the Work (“SOW”) or other ordering document (i.e., a quote, order, order acknowledgment customer requires non-stop immediate corrective action, regardless of time of day or invoice) which contains a description of the System. All Services and Documentation or day of the week as viewed by a customer
    [Show full text]
  • PDF Python 3
    Python for Everybody Exploring Data Using Python 3 Charles R. Severance 5.7. LOOP PATTERNS 61 In Python terms, the variable friends is a list1 of three strings and the for loop goes through the list and executes the body once for each of the three strings in the list resulting in this output: Happy New Year: Joseph Happy New Year: Glenn Happy New Year: Sally Done! Translating this for loop to English is not as direct as the while, but if you think of friends as a set, it goes like this: “Run the statements in the body of the for loop once for each friend in the set named friends.” Looking at the for loop, for and in are reserved Python keywords, and friend and friends are variables. for friend in friends: print('Happy New Year:', friend) In particular, friend is the iteration variable for the for loop. The variable friend changes for each iteration of the loop and controls when the for loop completes. The iteration variable steps successively through the three strings stored in the friends variable. 5.7 Loop patterns Often we use a for or while loop to go through a list of items or the contents of a file and we are looking for something such as the largest or smallest value of the data we scan through. These loops are generally constructed by: • Initializing one or more variables before the loop starts • Performing some computation on each item in the loop body, possibly chang- ing the variables in the body of the loop • Looking at the resulting variables when the loop completes We will use a list of numbers to demonstrate the concepts and construction of these loop patterns.
    [Show full text]
  • 7. Control Flow First?
    Copyright (C) R.A. van Engelen, FSU Department of Computer Science, 2000-2004 Ordering Program Execution: What is Done 7. Control Flow First? Overview Categories for specifying ordering in programming languages: Expressions 1. Sequencing: the execution of statements and evaluation of Evaluation order expressions is usually in the order in which they appear in a Assignments program text Structured and unstructured flow constructs 2. Selection (or alternation): a run-time condition determines the Goto's choice among two or more statements or expressions Sequencing 3. Iteration: a statement is repeated a number of times or until a Selection run-time condition is met Iteration and iterators 4. Procedural abstraction: subroutines encapsulate collections of Recursion statements and subroutine calls can be treated as single Nondeterminacy statements 5. Recursion: subroutines which call themselves directly or indirectly to solve a problem, where the problem is typically defined in terms of simpler versions of itself 6. Concurrency: two or more program fragments executed in parallel, either on separate processors or interleaved on a single processor Note: Study Chapter 6 of the textbook except Section 7. Nondeterminacy: the execution order among alternative 6.6.2. constructs is deliberately left unspecified, indicating that any alternative will lead to a correct result Expression Syntax Expression Evaluation Ordering: Precedence An expression consists of and Associativity An atomic object, e.g. number or variable The use of infix, prefix, and postfix notation leads to ambiguity An operator applied to a collection of operands (or as to what is an operand of what arguments) which are expressions Fortran example: a+b*c**d**e/f Common syntactic forms for operators: The choice among alternative evaluation orders depends on Function call notation, e.g.
    [Show full text]
  • Repetition Structures
    24785_CH06_BRONSON.qrk 11/10/04 9:05 M Page 301 Repetition Structures 6.1 Introduction Goals 6.2 Do While Loops 6.3 Interactive Do While Loops 6.4 For/Next Loops 6.5 Nested Loops 6.6 Exit-Controlled Loops 6.7 Focus on Program Design and Implementation: After-the- Fact Data Validation and Creating Keyboard Shortcuts 6.8 Knowing About: Programming Costs 6.9 Common Programming Errors and Problems 6.10 Chapter Review 24785_CH06_BRONSON.qrk 11/10/04 9:05 M Page 302 302 | Chapter 6: Repetition Structures The applications examined so far have illustrated the programming concepts involved in input, output, assignment, and selection capabilities. By this time you should have gained enough experience to be comfortable with these concepts and the mechanics of implementing them using Visual Basic. However, many problems require a repetition capability, in which the same calculation or sequence of instructions is repeated, over and over, using different sets of data. Examples of such repetition include continual checking of user data entries until an acceptable entry, such as a valid password, is made; counting and accumulating running totals; and recurring acceptance of input data and recalculation of output values that only stop upon entry of a designated value. This chapter explores the different methods that programmers use to construct repeating sections of code and how they can be implemented in Visual Basic. A repeated procedural section of code is commonly called a loop, because after the last statement in the code is executed, the program branches, or loops back to the first statement and starts another repetition.
    [Show full text]
  • An Introduction to Programming in Simula
    An Introduction to Programming in Simula Rob Pooley This document, including all parts below hyperlinked directly to it, is copyright Rob Pooley ([email protected]). You are free to use it for your own non-commercial purposes, but may not copy it or reproduce all or part of it without including this paragraph. If you wish to use it for gain in any manner, you should contact Rob Pooley for terms appropriate to that use. Teachers in publicly funded schools, universities and colleges are free to use it in their normal teaching. Anyone, including vendors of commercial products, may include links to it in any documentation they distribute, so long as the link is to this page, not any sub-part. This is an .pdf version of the book originally published by Blackwell Scientific Publications. The copyright of that book also belongs to Rob Pooley. REMARK: This document is reassembled from the HTML version found on the web: https://web.archive.org/web/20040919031218/http://www.macs.hw.ac.uk/~rjp/bookhtml/ Oslo 20. March 2018 Øystein Myhre Andersen Table of Contents Chapter 1 - Begin at the beginning Basics Chapter 2 - And end at the end Syntax and semantics of basic elements Chapter 3 - Type cast actors Basic arithmetic and other simple types Chapter 4 - If only Conditional statements Chapter 5 - Would you mind repeating that? Texts and while loops Chapter 6 - Correct Procedures Building blocks Chapter 7 - File FOR future reference Simple input and output using InFile, OutFile and PrintFile Chapter 8 - Item by Item Item oriented reading and writing and for loops Chapter 9 - Classes as Records Chapter 10 - Make me a list Lists 1 - Arrays and simple linked lists Reference comparison Chapter 11 - Like parent like child Sub-classes and complex Boolean expressions Chapter 12 - A Language with Character Character handling, switches and jumps Chapter 13 - Let Us See what We Can See Inspection and Remote Accessing Chapter 14 - Side by Side Coroutines Chapter 15 - File For Immediate Use Direct and Byte Files Chapter 16 - With All My Worldly Goods..
    [Show full text]
  • Software Engineering Software Maintenance
    SOFTWARE ENGINEERING SOFTWARE MAINTENANCE Software maintenance is the process of modification or making changes in the system after delivery to overcome errors and faults in the system that were not uncovered during the early stages of the development cycle. LEARNING OBJECTIVES • To study on why maintenance is an issue. • To study on reverse engineering and limitations. • To organize data. • To check what the system does. SOFTWARE MAINTENANCE The IEEE Standard for Software Maintenance (IEEE 1219) gave the definition for software maintenance as “The process of modifying a software system or component after delivery to correct faults, improves performance or other attributes, or adapt to a changed environment.” Maintenance Principles 100 Hardware Development 60 Software 20 Maintenance Percent of total cost total of Percent 1995 2000 2010 The IEEE/EIA 12207 Standard defines maintenance as modification to code and associated documentation due to a problem or the need for improvement. Nature of Maintenance Modification requests are logged and tracked, the impact of proposed changes are determined, code and other software artifacts are modified, testing is conducted, and a new version of the software product is released. Maintainers can learn from the developer´s knowledge of the software. Need for Maintenance Maintenance must be performed in order to: • Correct faults. • Improve the design. • Implement enhancements. • Interface with other systems. • Adapt programs so that different hardware, software, system features, and telecommunications facilities can be used. • Migrate legacy software. • Retire software Tasks of a maintainer The maintainer does the following functions: • Maintain control over the software´s day-to-day functions. • Maintain control over software modification.
    [Show full text]
  • 6Up with Notes
    Notes CSCE150A Computer Science & Engineering 150A Problem Solving Using Computers Lecture 05 - Loops Stephen Scott (Adapted from Christopher M. Bourke) Fall 2009 1 / 1 [email protected] Chapter 5 CSCE150A 5.1 Repetition in Programs 5.2 Counting Loops and the While Statement 5.3 Computing a Sum or a Product in a Loop 5.4 The for Statement 5.5 Conditional Loops 5.6 Loop Design 5.7 Nested Loops 5.8 Do While Statement and Flag-Controlled Loops 5.10 How to Debug and Test 5.11 Common Programming Errors 2 / 1 Repetition in Programs CSCE150A Just as the ability to make decisions (if-else selection statements) is an important programming tool, so too is the ability to specify the repetition of a group of operations. When solving a general problem, it is sometimes helpful to write a solution to a specific case. Once this is done, ask yourself: Were there any steps that I repeated? If so, which ones? Do I know how many times I will have to repeat the steps? If not, how did I know how long to keep repeating the steps? 3 / 1 Notes Counting Loops CSCE150A A counter-controlled loop (or counting loop) is a loop whose repetition is managed by a loop control variable whose value represents a count. Also called a while loop. 1 Set counter to an initial value of 0 2 while counter < someF inalV alue do 3 Block of program code 4 Increase counter by 1 5 end Algorithm 1: Counter-Controlled Loop 4 / 1 The C While Loop CSCE150A This while loop computes and displays the gross pay for seven employees.
    [Show full text]
  • Read Ms. Shaw's First Amended Complaint
    Janet L. Goldstein Peter W. Chatfield THE MARTYN FIRM, PLLC PHILLIPS & COHEN LLP 1054 31st Street, NW 2000 Massachusetts Ave., NW Washington, D.C. 20007 Washington, D.C. 20036 Tel: (202) 965-3060 Tel: (202) 833-4567 Fax: (202) 965-3063 Fax: (202) 833-1815 Jonathan A. Willens (JW-9180) JONATHAN A. WILLENS LLC 217 Broadway, Suite 707 New York, New York 10007 Tel: (212) 619-3749 Fax: (800) 879-7938 Attorneys for qui tam plaintiff Ann-Marie Shaw UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF NEW YORK UNITED STATES OF AMERICA ) 06 CV 3552 (DLI) (SMG) ex rel. ANN-MARIE SHAW ) and ) AMENDED COMPLAINT ) FOR VIOLATIONS OF STATE OF CALIFORNIA ex rel.ANN-MARIE SHAW ) FEDERAL AND STATE DISTRICT OF COLUMBIA ex rel.ANN-MARIE SHAW ) FALSE CLAIMS ACTS STATE OF FLORIDA ex rel.ANN-MARIE SHAW ) STATE OF HAWAII ex rel.ANN-MARIE SHAW ) STATE OF ILLINOIS ex rel.ANN-MARIE SHAW ) COMMONWEALTH OF MASSACHUSETTS ) ex rel.ANN-MARIE SHAW ) STATE OF NEVADA ex rel.ANN-MARIE SHAW ) COMMONWEALTH OF VIRGINA ) ex rel.ANN-MARIE SHAW ) STATE & CITY OF NEW YORK ) ex rel.ANN-MARIE SHAW, ) ) JURY TRIAL DEMANDED Plaintiffs, ) ) FILED UNDER SEAL v. ) ) CA, INC., ) ) Defendant. ) _______________________________________________ ) Through her attorneys, plaintiff and qui tam relator Ann-Marie Shaw, for her Amended Complaint against Defendant CA, Inc. (“CA”), formerly known as Computer Associates International, Inc. or “Computer Associates,” alleges as follows: FACTS COMMON TO ALL COUNTS A. Introduction 1. This is a civil action to recover damages and civil penalties arising from false and/or fraudulent statements, records, and claims made and caused to be made by the Defendant CA and/or its agents and employees in violation of the Federal Civil False Claims Act, 31 U.S.C.
    [Show full text]