An empirical study into COBOL type inferencing

Abstract

In a typical COBOL program, the data division consists of 50% of the lines of code. Automatic type inference can help to understand the large collections of variable declarations contained therein, showing how variables are related based on their actual usage. The most problematic aspect of type inference is pollution, the phenomenon that types become too large, and contain variables that intuitively should not belong to the same type. The aim of the paper is to provide empirical evidence for the hypothesis that the use of subtyping is an effective way for dealing with pollution. The main results include a tool set to carry out type inference experiments, a suite of metrics characterizing type inference outcomes, and the experimental observation that only one instance of pollution occurs in the case study conducted.

Type-Flow Analysis for Legacy Cobol Code

“…• The type inference 4 rules given in (van Deursen and Moonen, 2001) are sometimes trivial. We define a type-system that reconstruct more detailed type information, e.g.…”

“…system has been proposed several times in more articles with some additions -we might therefore refer to either (van Deursen and Moonen, 1998), (van Deursen and Moonen, 2001), (van Deursen and Moonen, 2000), (Kuipers and Moonen, 2000) or (Moonen, 2003). 3 Syntax of types in (van Deursen and Moonen, 1998) oddly carries along the variable identifiers and picture format strings as is, leaving unclear how the type environment and type comparisons formally related to them.…”

“…• According to (van Deursen and Moonen, 2001), pollution occurs whenever a type-equivalence involves types that are not equivalent or subtypes: we do not handle this as a special case, but it automatically comes from non-singleton choices within flow-types, which are natively supported by our type-system and do not require any further processing.…”

“…model the COBOL picture system without approximating storage format information such as computational fields or the amount of digits in a numeric, in order to reconstruct the exact inmemory representation of datatypes and perform precise comparisons among the many formats COBOL supports; 2. deal with what in (van Deursen and Moonen, 2001) is called pollution in such a way that no complex relational property system among types is needed, by tracking type alterations that variables are subject to in the following scenarios: (a) when data is reused for different purposes in a program: many COBOL programmers are used to this practice in order to save memory and the result is often poor maintainability and errorproneness; (b) when the language performs an implicit datatype cast, reformatting values to fit target variables, either at compile-time or at run-time. 3. deal with branches in the program flow that are not statically decidable (i.e.…”

Source code based function point analysis for enhancement projects

“…So, false positives do not compensate false negatives. We can minimize both types of errors by applying an additional data flow analysis (for a possible implementation, see [2] and [4]). This holds particularly for the recognition of the transactional functions: -Finding fields that are related to I/O statements, such that…”