AlllOb 1713QM

NATL INST. OF STAND & TECH

111

NBSIR 83-2639

Cost-Benefit Impact Study on the

Adoption of the Draft Proposed

Revised X3.23 American National

Standard Programming Language

COBOL

Prepared for U.S. DEPARTMENT OF COMMERCE

Center for Programming Science and Technology

Data Management and Programming Languages Division

Washington, DC 20234

March 1983

NBSIR 83-2639

< COST-BENEFIT IMPACT STUDY ON THE

ADOPTION OF THE DRAFT PROPOSED

REVISED X3.23 AMERICAN NATIONAL

STANDARD PROGRAMMING LANGUAGE

COBOL

national bureau

of STANDARDS

LIBRARY APR 8 1983

mvaoe.-ctf

Marco Fiorello

Fiorello, Shaw, and Associates

John Cugini

Institute for Computer Science and Technology

March 1983

Prepared for U.S. DEPARTMENT OF COMMERCE

Center for Programming Science and Technology

Data Management and Programming Languages Division

Washington, DC 20234

U.S. DEPARTMENT OF COMMERCE, Malcolm Baldrige, Secretary

NATIONAL BUREAU OF STANDARDS. Ernest Ambler. Director

TABLE OF CONTENTS

ABSTRACT 2

EXECUTIVE SUMMARY 3

1.0 INTRODUCTION 4

1.1 Background And Overview 4

1.2 Study Objectives 4

1.3 Study Scope And Qualifications 5

1.4 Reasons For Revising The Current COBOL Standard . 6

2.0 TECHNICAL ISSUES 7

2.1 Substantive Changes And Related Issue? 7

3.0 METHODOLOGY AND ANALYSIS 8

3.1 Framework 8

3.2 Base Case Statistics 8

3.3 Impact Areas 19

3.4 Quantitative Impacts 19

3.5 Qualitative Impacts 32

3.6 Sensitivity Analysis 35

4.0 FINDINGS 38

4.1 Interpretation 38

4.2 Recommendations 38

REFERENCES 41

APPENDIX A BASIC COST-BENEFIT ANALYSIS METHODOLOGY

APPENDIX B INCOMPATIBILITIES BETWEEN COBOL-74 (FIPS 21-1) AND

COBOL-8X [ANS-81]

APPENDIX C SOURCES OF SAMPLE PROGRAMS AND AGENCIES INTERVIEWED

APPENDIX D SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL

PROGRAMS

EXHIBITS:

3-1 Base Case Parameters 10

3-2 Distribution of Programs by Size 11

3-3 Distribution of Programs by Age 13

3-4 Summary of Incompatibility Frequencies 14

3-5 Proposed COBOL Revisions - Potential Impact Areas . . 17

3-6 Impact Parameters and Factors 20

3-7 Complexity Classes 25

3-8 Cost Analysis of Incompatibilities 31

3-

9 Sensitivity Analysis 37

4-

1 Summary of Impacts for the Proposed COBOL Standard . 40
Page 2

ABSTRACT

The purpose of the study is to assess the estimated costs and

benefits for the Federal Government which would result from

adoption of the proposed revision of American National Standard

COBOL as a Federal Information Processing Standard (FIPS)

.

Potential benefits of $90.2 million have been identified,

stemming primarily from improved productivity in both the

development and maintenance of COBOL programs. Estimated costs

of $17.9 million have been identified, arising principally from

the effort needed to convert old COBOL programs to the new

specification, which is incompatible in some respects with the

current specification. In support of the study, we conducted

interviews with Federal ADP managers and officials, and also

analyzed over one thousand Federal COBOL programs for various

syntactic characteristics. The study concludes that the

potential benefits of a new standard outweigh the estimated

costs.

Key words: COBOL; compatibility of programming language

standards; conversion costs for COBOL programs.; cost-benefit

analysis of COBOL standards; Federal use of COBOL; FIPS for

COBOL; standardization of COBOL.
Page 3

EXECUTIVE SUMMARY

The revision of a widely-used language standard, such as COBOL,

necessarily involves a trade-off between enhancement of the

language and compatibility with existing code.

Potential costs are concentrated in the conversion of old code.

This cost depends strongly on the frequency and complexity of the

various changes being made to COBOL.

Potential benefits are expected both in the development of new

code and the maintenance of existing code, as modern coding

techniques become prevalent in the Federal Government.

While not exact, it is possible to make a quantitative estimate

of these costs and benefits. The result of the analysis herein

is a potential cost of $17.9 million and estimated benefits of

$90.2 million (net benefit: $72.3 million).

The maximization of benefits and minimization of costs depends

strongly on good DP management practice. In particular, DP staff

should be encouraged to take advantage of the new features

provided in the revision of COBOL, and there should be a systematic effort to discourage the use of features which are

being dropped from the standard.
Page 4

1.0 INTRODUCTION

1.1 Background And Overview

The goals of the ICST Federal ADP standards program are to

develop and issue standards and guidelines for competitive and

economic procurement of data processing equipment, efficient

management and utilization of ADP, improved protection of ADP

resources, and increased productivity of the Federal work force.

This analysis concerns Federal Information Processing

Standard (FIPS) COBOL, one of the high level programming language

standards. The basic objectives of these standards are: (1) to

achieve the long-recognized advantages that are inherent in the

use of higher level languages, and (2) to maximize and protect

program investments by making it easier and less expensive to

exchange programs among different computer systems, including

replacement systems.

In developing and maintaining standards and guidelines for

ADP activities within the Federal government, ICST works closely

with voluntary standards bodies, such as the American National

Standards Institute (ANSI) and the International Standards

Organization (ISO). FIPS 21-1, the current Federal standard for

COBOL, is based on ANSI standard X3. 23-1974 [ANS-74] (often

called COBOL-74) . ANSI committee X3J4 has proposed a revision to

COBOL-74, and it is this revision which is under review by

various ANSI participants, including ICST. Such a revision is of

interest to ICST since it represents a potential basis for a revised FIPS for COBOL.

This study is presented in four major sections and four

appendices. In the rest of this section, the study objectives,

scope and qualifications, and rationale for the proposed changes

are presented. Section two identifies the major technical issues

concerning the proposed changes. Section three presents the

study methodology and analysis used to determine the cost and

benefits. Lastly, section four presents the interpretations of

the study findings and the recommendations. The references

follow the main body of the report. Appendix A contains an

outline of the study methodology, Appendix B contains a list of

the substantive changes potentially affecting existing COBOL

programs, Appendix C provides a list of the agencies visited and

the agencies which supplied sample programs, and Appendix D

describes the automated system which was used to analyze the

sample programs.

1.2

Study Objectives

The specific objectives of this study are to assess the

costs and benefits to the Federal ADP community of the proposed

changes to COBOL-74, and to recommend one of the following

actions: (a) reject the proposed revision and continue with FIPS
Page 5

21-1 (this is the status quo, or so-called "Base Case" option)

,

(b) adopt the ANS X3.23 proposed revision as a new FIPS (21-2) , or (c) attempt to modify the revision so as to limit costs or

enhance benefits to the Federal Government, thus establishing it

as a more valuable base for a new FIPS.

1.3 Study Scope And Qualifications

This study scope is limited to the COBOL-related impacts on

the Federal ADP community. Of course similar impacts may be

expected in the private sector insofar as the characteristics of

its COBOL usage resemble those of the Federal sector.

In this analysis, we are concerned with impacts that may

result if the proposed changes to ANSI COBOL-74 are also adopted

in the FIPS for COBOL. Data available on applications software

development and maintenance in the Federal government are general

and approximate in nature, and are particularly limited regarding

any one specific programming language such as COBOL (although

COBOL is by far the most commonly used language within the

Federal government, and therefore can hardly be regarded as

atypical) . We augmented the available general data with staff

interviews at nine Federal agencies and with a detailed analysis

of a sample of 1068 COBOL programs from eleven Federal agencies.

Appendix C shows which agencies participated in the interviews

and which contributed sample programs.

The more detailed information obtained from the interviews

and sample program analysis enabled us to estimate the magnitudes

of the likely costs and benefits attributable to the adoption of

the proposed, revised COBOL standard. However, these estimates

are not intended as precise determinations of those costs and

benefits, as they necessarily reflect many approximations and

subjective inputs and interpretations.

The revision of the ANSI COBOL Standard is an ongoing

process at the time of this writing, and the conclusions of this

report are accordingly subject to change. ANSI committee X3J4

has the responsibility for acting on public comments and a definitive evaluation must wait until the revision takes final

shape. If warranted by further changes in the proposed revision,

or by additional data gathered from Federal agencies, this report

may be updated at a later time to reflect those changes.

The principal assumptions and specifications used in this

study include:

1. The new FIPS will be introduced in 1984 and the first

compilers will be available in 1984 - 1985.

2. The study horizon is 10 years, 1984 - 1993.
Page 6

3. Static relationships are appropriate, and the statistics

and trends derived from the 1979 - 81 Federal ADP data

are representative for the study horizon.

4. A new FIPS for COBOL would be complied with, converted

to, and utilized in the same way FIPS 21-1 (COBOL-74)

was, relative to FIPS 21 (COBOL-68)

5. The impacts will be based on the changes proposed in

[ANS-81] , (the blue book) which was current as of

September 1981 and upon relevant subsequent actions by

ANSC/X3J4.

6. The impact of a revised COBOL standard will be assessed

relative to the existing standard FIPS 21-1 (COBOL-74) . Thus, as far as possible, any impacts stemming from

COBOL-74 itself will be discounted, since its adoption

is not at issue.

7. The cost estimates will be made in 1983 constant

dollars.

1.4 Reasons For Revising The Current COBOL Standard

The reasons most frequently given in support of the proposed

changes to the current ANSI COBOL standard are that they will

improve the language's capabilities and ease-of-use, and limit or

remove error-prone, useless, and redundant features [NELS-81a]

[NELS-81b] , [DUBN-81] . The intent is to enhance application

programming productivity, facilitate program portability and

improve program maintainability.

Notwithstanding the apparent compatibility of the above

considerations with the official objectives of FIPS COBOL, the

bottom-line criterion by which a new COBOL standard must be

judged is whether or not the Federal ADP community will be better

off adopting the proposed changes, as compared to the current way

of doing business.
Page 7

2.0 TECHNICAL ISSUES

In this section the proposed changes are identified, and

various related technical issues are discussed.

2.1 Substantive Changes And Related Issues

Of interest in this analysis are those proposed changes that

are expected to have a substantive effect on existing programs.

Also, enhancements to the language (which do not affect existing

programs) are examined for their potential impact.

The basic technical issues related to all the proposed

changes fall into four categories:

1. Productivity - How do the changes affect COBOL's scope

of application and use of new programming techniques?

2. Maintenance - How do the changes affect COBOL's

error-prone and ambiguous features and the

maintainability of programs?

3. Conversion - How do the changes affect the portability

of COBOL programs across various systems? Do they

protect the investment in existing COBOL programs?

4. Training - Do the changes make it easier to learn and

remember the COBOL language?

Without question, the dominant technical issue on the cost

side is that of conversion. This cost manifests itself as the

extra effort needed to purge existing programs of code dependent

on features of COBOL-74 which have been deleted or changed. As

opposed to this cost, which is concentrated and visible, the

benefits are necessarily somewhat more speculative and dispersed

more evenly throughout Federal ADP practice (and are accordingly

more difficult to measure exactly)

.
Page 8

3.0 METHODOLOGY AND ANALYSIS

3.1 Framework

The cost-benefit analysis framework used in this study is

based on the preliminary guidelines presented in [FIOR-78]

1. Specification of the Goals and Objectives

2. Preparing the Standard Definition Statement

3. Defining the Base Case

4. Selecting the Cost-Benefit Impact Areas

5. Constructing the Model

6. Obtaining the Data

7. Estimating and Evaluating the Cost-Benefit

8. Presenting and Interpreting the Results

Steps 1 and 2 are discussed in Sections 1 and 2, pertinent

results from steps 3-7 are presented below in this Section, and

step 8 is discussed in Section 4 on Findings.

3.2

Base Case Statistics

The Base Case statistics are derived from various reference

materials, cited at the end of this document, and the study

survey and program sample. The pertinent statistics are

summarized in Exhibits 3-1 to 3-5, and brief descriptions are

given below.

3.2.1 Programmer Pool -

o For the past 10 years the number of Federal agency staff

programmers has remained fairly steady in the range of

118,000 to 120,000 staff-years [NBS-81] .

o Of those work-years, roughly 60% were primarily for

COBOL-related activities in 1980, with a growth to 65%

projected for 1985 [GRAY-81]

o Depending upon the Federal agency, the annual programmer

turnover rate will vary from a low of 10% to a high of

30%. A reasonable average appears to be 20%.
Page 9

o All of the agencies contacted have or arrange training

courses for new programmer staff.

o In most installations, more than half of the staff are

devoted to maintenance (corrective, adaptive and

perfective) activities which reflects the life cycle

distribution of application software costs [LISW-81]

,

[GA0-81b] , [BOEH-81]

o Based on very limited data, it appears that on the

average a programmer spends 15% to 25% of available time

performing the coding function.

3.2.2 COBOL Program Inventory -

o There are roughly 500,000 application software programs

in the Federal inventory. Of these, 50 to 60% are in

some form of COBOL.

o Very few, 5-10%, of these 250,000 to 300,000 COBOL

programs are in full conformance with the current COBOL

FIPS 21-1 [SHOE-80]

o The average COBOL program in our sample contains about

1270 lines of source code (see Exhibit 3-2) and was

developed about 6.0 years ago (see Exhibit 3-3). This

latter figure compares reasonably well with the 5.4 year

estimate in [GAO-81b]

In our sample of 1068 COBOL programs, with over 1.3 million

lines of code from 11 Federal agencies, roughly 80% use one or

more of the 50 proposed incompatible changes analyzed in this

study. if we discount the somewhat special case of the

incompatibility concerning the DISPLAY verb (see below) , this

figure drops to about 40%. The specific frequencies of

occurrence are shown in Exhibit 3-4. See Appendix B for a description of the incompatibilities, by number.

Note that in Exhibit 3-4 the statistics are broken down by

contributing agency, as well as by individual incompatibility.

In cases where there were two separate systems within one agency,

these systems were kept separate in the figure; thus, eleven

agencies accounted for thirteen systems. Since each agency

contributed a different number of programs, there is some

question as to whether the summary statistics should be weighted

by program, or by agency. Both are computed and displayed.

Where necessary for the analysis, we used a reasonable

intermediate figure. Of course, the greater the disagreement

between the two averages, the greater the uncertainty about what

percentage is truly representative of the entire Federal

inventory.
coM

0) fa

<ug

Jh

to fa

<D

(0

to u

d)CO

tO OQI co

fa •H

X!

W

En

W Eh U CO

fa

W

DO fa CO O

faW

Eh

fa2g<

fa

uM

EhCO

Eh

faO

>H

fa

fa

fa

JZX

fa 2OM

EH

faM

faU

CO

fa

fao

CQ2

Jh

co

faQO2 uM

EhCOM2M

COco

fa

fa

0)

g fa >1 <u (0 to <1) >H

jh

g > a

OVH

M

g '1 ,—, 1—, 1—, i—, , 0 fa 3 to in r—t <—i

1—1 1—1

i—1

<N CN X) jq

JH CO CO CO f" 00 .-I 00 00 00 00 00

H •—i

fa fa 1 1 00 1 1 1 1 1 00 00

>i >i fa >H 1 Jh SS Jh

UU 1 1 Eh P TD TJ O <C CO < fa < CO CO O O co co 3 3 D fa CQ fa O fa V O < <

<j a) fa faa

O 2 U CQ

O fa fa

UO

W CQ CO CO 1-J 1 1 1 i—1 1—i 1—1 1—1 '

1 O o o dP dP dP dP o o ID o 1 O O o CM o CM VO CO 1 •. i-l * o o in o CM \ CO i-l rH

rH11 co • u

JH K. t >i M T3 \ o o o dP dP CO dJ CM dP dP O o o O O •H M • O O o o CM o CM ID fa CO CO VO o i—l

10 3 fa o 00 •H TO CM o tD 1—1 a T3 o CM 1—1

CD to CM a. c

{/> CO 3

JH -

<D o M O 3 00 o o o dP dP a - dP dP o o o LD ID g r- I O O o CO o fa 0 CM LD ID 1 —i

CJ v> o ID —• o I—1

CM 1—

cnG

•H CO CD <D <u >1 g g 0 g J-l JH to •H M •»H P fa g fa •H 0 d) M C M O to fa CO p 5 g 1 CD P CQ JH (0 J-l g fa >h e JH

CO

O cn P to 4H CM to VM JH <d

a CD CD 0 O 0 co a) fa fa JH >1 to (0 g 0 g O o co u >4 to to cn jh M QJ g fa g C

fa i—1

fa fa 1 P P 0 to

w >, (0 CD to to fa M to \ to J-l CO CO JH t-l 1 JH > JH G C fa JH CO J-I <y fa to d) VM cn cd cn cd <V 0) co (1) cn e fa fa fa CO fa fa 0 TD 0 -u g 04 TD g c id e Q a o fa X to Jh Jh C C 0 <d to •H <u to < cn < CQ to P f0 P a s dl -H

JH 1—1

fa Jh fa fa JH c o JH to fa CO <d to

OJ oj cn cn fa -H 4H

u <D 3 •H VM

C *m e > > • 0 • • 0 0 'O 0 T3 C t0 Jh 0 0 0 o 0 M 0 0 JH 0 c d) C > d> c c O T3 2 fa 2 2 fa <#> o dP o fa c < 04 dP 0 dP 0

fa fa fa 2 fa CO Jh Eh Eh

uu fa

a fa CO <Caa 2 o 2 2 2 fa u fa CO fa fa

i'i
LINES/NO.

PGMS/CUMULATIVE

%

PGMS/CUMULATIVE

%

LINES

100/

36/

3.37%/

0.19%

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

x

X

X

X

X

X

X

X

X

X

X X

X X

X X

. X X XXX XXX XXX

XXX

XXX

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X

X

X

X

X X

X X

X X XX XXX

XXX XXX

XXX XXX ..XXX

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X X X X X

X X X X X X X X

X X X X

X x X X

X

X

X

X

X

X

X X

X X

X X

X X

X X

X X

X X

X X

X X

X X

XXXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX XXX XXX XXX

XXX XXX

X X

X X

X X

X X

X X

X X XX XXX

XXX XXX XXX XXX

XXX

X

X

X

X

X

X X

X X XXX XXX

XXX XXX XXX

XXX

XXX

XXX

XXX XXX XXX

X

X

X

X

X

X

X

X

X

X

X XXX XXX XXX

XXX XXX

X

X X

X X

X X

X X

X X XX..

X X X X

X X X X X

X X X X X X

X X X X X X

X X X X X X

X X X X X X

X X X X X X

X X X X X X

X X X X X X xxxxxxxx

xxxxxxxxx xxxxxxxxxx

xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx

X

X

X

<#><#><#>(#><#>!#><#>(#>(#>(#>(#>(#>

: x

! X X

X X X

X X X X X

X X X XXX X X

X X X XXX X X

X X X XXX X X X X

X X X XXX X X X X X X

X X X XXX X X X X X X X X X X

X X X XXX X X X X X X X X X X X X X X X X X X X X

X X X XXX X X X X X X X X X X X X X X X XXX XXX X X X

dP dp dp dP dP dP dp dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP o 00 00 CM CO 00 o CM VO I"* ON O TT CM 00 in in in r- vo CO ON CO CM in VO

CO O CO ON C'H in CO o CO CO 00 •'T ON in rH O vo VO CM VO CO •*9

* in m m r- rH

<N m VO 00 o O rH CO in vo r- r- oo 00 ON O o rH CM co in vo r- 00 00 00 ON o

m in in in in vo VO VO VO VO VO VO vo vo VO VO vo r- r-~ r- r* r* r- r* r- 00 \<#> \\dP dP \wc#>c#>c#> \dP dP dP dp \\dP dP \dP \\dP dP \dP \\\\\ \\\\ssN\\\\ dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP dP o O OV •<T o in co on co in •<r co rH O ON 00 r- ^ CM H O a\ vo in CO CO CO rH O

r- VO CO o oo m VO rH 00 h ov co in ON rH CM CO in o co m vo r- *H CO vo VO VO ON O

v

O

oo on on o OHHtN CM CM co CO CO CO h* m in in in in VO VO VO vo vo vo

00 00 00 oo oo on on ov ov ov <j\ on <Tv on ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON ON

H CM ID [— o ro VO

dP # DC dP T •O' <Tl r-l (N O O .H \dP <#> dP

<r h in o rr r~

OO^O^O^O^O^O^O^O^O^O^O^O^O^O^OO^O^O^OO^O OOO OOO OOOOOO O OO OOOOOO OOO o' o' O OC3C3C3 oooooooooooooooooooooooooooooooooooooooooooooooooooooo

r'im*jtinior-co(riO>-i<Nro'i, inier~coaio>-((Nm'», invDr-'00(7io<HfNro*i'inior-co(riOrHCNr>-)*rini©r~co<jio.-j cNr'i^in

Exhibit 3-2 (continued)

5600/ 2/ 97.19%/ 80.95% XX

5700/ 2/ 97.38%/ 81.77% XX

5800/ 0/ 97.38%/ 81.77%

5900/ 0/ 97.38%/ 81.77%

6000/ 1/ 97.47%/ 82.20% X

6100/ 1/ 97.57%/ 82.65% X

6200/ 0/ 97.57%/ 82.65%

6300/ 1/ 97.66%/ 83.11% X

6400/ 0/ 97.66%/ 83.11%

6500/ 0/ 97.66%/ 83.11%

6600/ 3/ 97.94%/ 84.54% XXX

6700/ 1/ 98.03%/ 85.03% X

6800/ 0/ 98.03%/ 85.03%

6900/ 0/ 98.03%/ 85.03%

7000/ 1/ 98.13%/ 85.53% X

7100/ 2/ 98.31%/ 86.56% XX

7200/ 1/ 98.41%/ 87.08% X

7300/ 0/ 98.41%/ 87.08%

7400/ 0/ 98.41%/ 87.08%

7500/ 0/ 98.41%/ 87.08%

7600/ 0/ 98.41%/ 87.08%

7700/ 1/ 98.50%/ 87.64% X

7800/ 1/ 98.60%/ 88.21% X

7900/ 0/ 98.60%/ 88.21%

8000/ 1/ 98.69%/ 88.79% X

8100/ 1/ 98.78%/ 89.39% X

8200/ 1/ 98.88%/ 89.98% X

8300/ 0/ 98.88%/ 89.98%

8400/ 1/ 98.97%/ 90.59% X

8500/ 0/ 98.97%/ 90.59%

8600/ 1/ 99.06%/ 91.21% X

8700/ 0/ 99.06%/ 91.21%

8800/ 1/ 99.16%/ 91.85% X

8900/ 0/ 99.16%/ 91.85%

9000/ 2/ 99.34%/ 93.16% XX

9100/ 0/ 99.34%/ 93.16%

9200/ 0/ 99.34%/ 93.16%

9300/ 1/ 99.44%/ 93.83% X

10800/ 1/ 99.53%/ 94.62% X

11900/ 1/ 99.63%/ 95.49% X

13500/ 1/ 99.72%/ 96.47% X

14200/ 1/ 99.81%/ 97.50% X

17100/ 1/ 99.91%/ 98.74% X

17300/. 1/100. 00%/100. 00% X
Exhibit 3-3 Distribution of Programs by Age

MONTHS/NO. PGMS/CUMULATIVE % PGMS

6/ 15/ 2.41% XXXXXXXXXXXXXXX

12/ 37/ 8.36% XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

18/ 24/ 12.22% XXXXXXXXXXXXXXXXXXXXXXXX

24/ 44/ 19.29% XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

30/ 30/ 24.12% XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

36/ 36/ 29.90% XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

42/ 25/ 33.92% XXXXXXXXXXXXXXXXXXXXXXXXX

48/ 25/ 37.94% XXXXXXXXXXXXXXXXXXXXXXXXX

54/ 23/ 41.64% XXXXXXXXXXXXXXXXXXXXXXX

60/ 23/ 45.34% XXXXXXXXXXXXXXXXXXXXXXX

66/ 36/ 51.13% XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

72/ 32/ 56.27% XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

78/ 13/ 58.36% XXXXXXXXXXXXX

84/ 20/ 61.58% XXXXXXXXXXXXXXXXXXXX

90/ 28/ 66.08% XXXXXXXXXXXXXXXXXXXXXXXXXXXX

96/ 24/ 69.94% XXXXXXXXXXXXXXXXXXXXXXXX

102/ 28/ 74.44% XXXXXXXXXXXXXXXXXXXXXXXXXXXX

108/ 11/ 76.21% XXXXXXXXXXX

114/ 10/ 77.81% XXXXXXXXXX

120/ 16/ 80.39% XXXXXXXXXXXXXXXX

126/ 13/ 82.48% XXXXXXXXXXXXX

132/ 23/ 86.17% XXXXXXXXXXXXXXXXXXXXXXX

138/ 17/ 88.91% XXXXXXXXXXXXXXXXX

144/ 12/ 90.84% XXXXXXXXXXXX

150/ 9/ 92.28% XXXXXXXXX

156/ 13/ 94.37% XXXXXXXXXXXXX

162/ 7/ 95.50% XXXXXXX

168/ 1/ 95.66% X

174/ 12/ 97.59% XXXXXXXXXXXX

180/ 8/ 98.87% XXXXXXXX

186/ 4/ 99.52% XXXX

192/ 0/ 99.52%

198/ 1/ 99.68% X

204/ 1/ 99.84% X

210/ 1/100.00% X
dP dP dP dP dP dP dP dP dP in CM 00 O 00 VO ON 00 o O rH o rH in ro ro rH

• rH vo *d* in O rH o ON 00 CM

(M 00

ON VO

ro o

O rH

r^* ro

ro

rH H* ro o 00 iH

cn

VO o

o o

dP dP dP dP dP dP dP dP dP oH'j, oini/iH^oooo;(soooo^oon^a'oooooco^aNa'oo oo in rH o h H rH in on <}• vo on cs on in

h* inro o

r*

in

ON CM

VO o

O CM ro rvo vo

in

in in

dP dP dP dP dPdPdP dPdP ooooooooooocor-ooooo o h ro in-aNOOoooinrooooo

o oo in oh cm cm o

rH O

00 CM ro

in ** o oo

on ro

rH ro

cm rcx> o in vo dPdPdP dP dPdPdP dPdP OiHOOOOOOOOOOOOOOOOOrOOl^OOOOOOOOOOOO ooo o ooo oo

o

rH

=**=

vo r*

vo rinon

CM

CM

on 00 o ro

inCM

00 O ro rH

• • rH 00

oo in

av ro

CM CM

VO CM

rH o in vo

VO

H* *d* CM VO

^5* rH O VO

ON CO

dPdPdP dP dPdPdP dPdP OiHr^OrHinoooooavaiooooo onr- ONONOOooo^rooooo CM CM tT CM o vo OCNCMVO in H O

Wr^ \\n\o\\\\H\\w\ d\r^ \H\\\\\\o \o\\ o ro cm o rH in o ooomrHooooo ocMOrHooooo^rr^o oo

o ^ rH r* in

CM rH

vo ro

vo ^

vo

CM CM o vo

CM

in

ro o CM ^

CM 00

ON VO

rH

rH CM

00 O in cm

00 00

r- vo

CM O

in on

vo in

dP dP dP dP dP dP dP dP dP oooooorHrooooooooooooroooooooooooovomrooo O O ro O O ON O rHOOvO

dPdPdP dP dPdPdP dPdP OVOOOO^finOOOOOOOOOOOOOinvOrO^OOOOOrHrHOOOO vo^ro o o o oo vo o

ON rH

“'d4 rH r*

in r* o ro

r- vo

vo

rH o

dPdPdP dP dPdPdP dPdP OOOOOOOOOOOOOOOOOO OOO OOO OOOOOOOOOOOOO o ooo oo

on r*

00

rH

rHo

r* in

on in ro rH

vo

cm ro

oo

in in

in vo

on o> o ON

in vo

r* on

ON CM

VO 00

^ vo

CM CM

dP dP dP dP dP dP dP dP dP dP “OrHroooinooooooooooooorHcor^TfooooorHcor^^roo in rH ro o o © in r* rH oo ri • • • • ••• • • \\o Win \o\\\\o\\\\\ o\o \n\\\\\\in \ro\\ OH OO O OOOO OOOOO rH 00 ooooovo oo oo *4 rH CM ro

CU 2 dPdPdP dP dPdPdP dPdP ooovooooooooooooooorHin^rooomooooorHinrHinoo rH O O O VO in rH vo vo

f

ro ro

ro ON

in cm

rorH

in

in vo

oo vo

CM

r- cm

vo vo

• • cm r- m on

r- rH rH CM

00 TT

on r-

• • o r"

r- oo

vo *<r

vo ON

vo ro

^ CM vo o

dPdPdP dP dPdPdP dPdP oooooooooooooooooincMinmmcMooooo^'r-vooNOO O OO O rHiHcOONrHiH rorocM

dPdPdP dP dPdPdP dPdP ocMrooooooooooooooooocMroiHCMoooooromoooo ooo o o o in in o

in in

•'d4 in

inoro

vo vo

ro cm

•• on a

o

9 b

as

55 J

dp ^p ^p jp OCM^OOOOOOOOOOOOOOOOCM^r^rOOOOOOOOOOOO vo

• o• o« o• o•••vo r- oo•• .o \o\\

dPdPdP dP dPdPdP dPdP OOOOOOOOOOOOOOOOOOOrO^OOOOOOOrHrHOOOO ooo o o in o rH ro o

I cm ro in vo co <jn oS 33333 3 5 338333 3 83

Exhibit

3-4

(continued)

00

dPa

ino £ 3 • • o o

rH

as

•M* CO 3

in

00

• • • • SO CN o CO

dP . dP _ . dP <r

oo r- •h oo O CM

r* s

# # # # dP # # # # tfd # OfNOOOOOOOOOO'^MC'HO)^3HhOH^OhVOOOHO)OhOnh vo vo co h o in cm cm os o co ^p o os os oo r*

in

dP # # dP # dP dP # dPdPdP cor^ooooooooorHvooooocor^OQOOOocMrHoooo^p^pooo in oo o o in o o p* o co »h o

dP dP dP dP dP dP dP dP dPdPdP ONcooooo©©ooooooooocMincMin©oo©ooo©»HmcMr^or^aD as ooovovooo co vo cm OOiOhH 00

in

dP dP dP dP dP dP dP dP dP dP dP WCMOOOOOOOOOOOrHi-)^r-lr-(r^^'COO<-lf-(OC>«POOOOOCM^ i

l OOO n o vo vo cm oo iH in vo cu o x* r» o • ••••••• • • • N'vf \\\\\\\\\\o\H\H\n\M \\^wrow\o\r- \\o CM ft O O O O O O O O O O » xr VD n vf N O 4 ON ooo VO o o cn ro cm «rm

dP dP dP dP dP dP dP dP dP dP dP OOOOOOOOOOOOOOOOOVNOOOOOOOOrHcr. oooooomooo o ooorHooo or^ o

dP dP VO ro as r* rH 00

• • CM as o

ao

dP dP dP ^P rH CO CO CO

os r- r- O P- oo • oo • TP • \ CO

r-f 00 \HO 00 >£ «*P o O CO CO in

<J\ 00 CM

dP dP dP in o in o O rH co o co o CO P-

• \ O \o \m o o rH O VO 00

VO rH VO rH »H ^P CO rH

dP dP dP ^P O 00 O CO O

»H O• • \ O \ in <n r- CM rH rH CO CM rH

dP dP dP O P- O CM rH o r- o p" in

• • >g vo o in as O .-1 H* rH in 00 ^P rH rH

dP dP dP o m o in rH CO co as co as VO

• \ oo \co

*p r- cm r*» rH rH CM CM

dP dP dP CM cm p- rH OS TP VO H* VO CO O • • \ f' \r» \<N

cm as o as O P- vo H4 vo 00 00 CM

dP dP dP cm r- CM P* oo as in oo in oo CO CM

• • • \ PO \rH

CO 00 rH 00 TP vo o O* as in Tp

dP dP dP 00 CO 00 CO CO P- r* P* CM

• • \ <N \<N \ r~

*p r- P- CM CM as as rH

dP dP dP dP dP dP dP dP dP dP dP rOOOOOOOOOOOOOOOOCNr'OOOOOOI^x*OOOOVO<MO--HPr> in o o o o o o r- orn xr crv

(N OOOOOOOOOCN

dP dP dP dP dP dP dP dP dP dP dP ooooooooooooooooogocooooooogocooooocovoooq o © © © r** © © r* ocom* o • • H • • CM \\\ OOO O \CM CM

VO WOO O

co

CM^OOOOOOOOOOOOOOOOOOOOOOO»HugOOOOjdjjHOO«

dP

^p o 00 ^P

rH • CM §S s

dP *p o 00 <*P H • \oo

cm as

r*

dP r* rCM *P

cm . \ r*

oo r*

ooinH dP

^P CM

in oo

a>

• •H . . 4J rH

dP xH <*> rH dP OOO H H 00 ^p in o H N H Q H’P

• XI C w • \\o •H \ 00 \in o o U H Cl qj in cm S

1/1 x ^

Q in in C cm H

^ \ va

in vo as

in vo

CM 9

dP

•*p cm VO CM \^’

as co co

dP dP dP dP o in oo in in co in OS rH co in CM vo CM CO Tp VO

• \\<M \os \H O VO CM as oo CM P" in co CO co VO as r* •• vo

CM OS

oo as §>B < in n as

ft <#> HJlvf a vo -\ro m <Ti iH

in

i <#>

I i— n

i"

; \nl

av rH

dP

in in

•H

•V dP 3 *p in CM rH rH rH CO o • \vo

co as aJ oo in

VO CM

CM 8

•H VO J3 m

<n w

' JJ

•H£xf

•y o

S ® 2 cJ £D *r l£3 r- ?5 o» o <n r> xr in vo i" oo <n o ^ <n ro xr in

<n Nnnnnnnnn^ xr xr « xr xr xr xf xf in m in in in in

Exhibit 3-4 (continued)

SUMMARY OF RESERVED WORDS:

RESERVED WORD OCCURRENCES

ALPHABET 2

CLASS 24

DAY-OF-WEEK 11

END-READ 7

END-RETURN 2

END-WRITE 2

EXTERNAL 22

FALSE 12

INITIALIZE 32

OTHER 34

REFERENCE 2

STANDARD-2 1

TRUE 17

Exhibit 3-5 Proposed COBOL Revisions - Potential Impact Areas

Impacts Evaluated Not Evaluated

Impact Areas Quantitative

and Elements Assessment

Qualitative

Assessment

Potential

Impacts

I. Procurement

Compiler Costs X

II. Operations

Training X

Program Development X

Program Maintenance X

Management of

Programming X

Documentation of

Application Software X

Processing Efficiency X

III. Conversion

Conversion of

Application Software X

IV. Automated Functional

Area Performance

Functional Enhancement X

Requirements Analysis X

Program Life Span X

V. General

Programmer Transferability X
Page 18

Another point about interpretion of the statistics is that

the detection of incompat ibilt ies was done by a syntactic scan of

the source code. Where the incompatibility involves a syntactic

change (e.g., the deletion of ENTER) , this is a reliable

procedure. In those cases where the semantics are being changed

or clarified (EXIT PROGRAM closing out PERFORMS, e.g.), however,

can be done is to look for source code where such a make a difference. This analysis

worst-case estimate, and is not

The DISPLAY incompatibility (number

especially striking example of this. Syntactically,

every single occurrence of the DISPLAY verb as an

incompatibility, even though the great majority of vendors

currently implement this verb as described .in the proposed

revision. See Appendix D for details concerning each

i ncompa t ib i 1 i ty

.

the best that

change might

therefore, a realistic.

represents

,

necessarily

53) is an

we counted

The age of programs was determined simply by the contents

(if any) of the DATE-WRITTEN paragraph. This is, of course, not

a foolproof metric. Moreover, it is not as easy as might be

supposed to formulate a precise definition of program age (e.g.,

how much does a program have to be altered before we would say

that the old program has not merely been modified, but has been

replaced by a new, different program?) . Nonetheless, we feel the

data is worth presenting, and it does agree with a previous GAO

estimate. We were able to find a DATE-WRITTEN entry in 58% of

the sample programs.

3.2.3 Application Program Conversion And Maintenance -

In the current setting, the source code for application

programs is updated for a variety of reasons:

1. Conversion to a new or modified host system (hardware or

software)

2. Accommodating modified functional requirements

3. Correction of errors detected in the code

4. Re-programming to reduce the number of compilers used or

to improve processing efficiency

There are no specific data on the updating attributable to

each of the above causes; only general statistics on the average

life cycle of a program are available.

The interviews with Federal ADP managers revealed that COBOL

programs are recompiled at least once a year because of

maintenance activities. In some installations, programs are

recompiled as many as 6 times annually. A reasonable average is

2-3 times per year.
Page 19

3.3 Impact Areas

FIPS cost-benefit impact areas are ADP-related activities in

which resources and/or outputs are potentially affected by the

proposed COBOL revisions. For this analysis, five major areas of

ADP activities were examined: Procurement, Operations,

Conversion, Automated Function Performance, and General. The 12

individual impact elements within the 5 areas that were analyzed

in this study are listed in Exhibit 3-5. The impact elements

fall into three categories: quantitative, qualitative, and

potential. The type of analysis associated with each of the

impact elements is designated by an "X" in the appropriate column

of Exhibit 3-5.

Of the 12 impact elements listed in Exhibit 3-5, it was

possible to assess three quantitatively: Program Development,

Program Maintenance, and Program Conversion. For these impact

elements, we were able to construct rough cost-benefit models,

and, importantly, adequate data was available.

Of the remaining impact elements, six were assessed

qualitatively and three were identified for their potential (but

not measured) impacts. Qualitative arguments are provided for:

Training, Processing Efficiency, Functional Enhancement,

Requirements Analysis, Program Life Span, and Programmer

Transferability. For these impact elements, there were strong

subjective inferences or plausible arguments that some aspect of

an impact can occur. These impact estimates, though imprecise,

represent potentially valuable and relevant aspects of the

cost-benefit effects of the proposed revisions to Standard COBOL.

The remaining three elements, Compiler Costs, Management,

and Documentation, are identified principally to indicate that

they were reviewed for potential impacts. For these elements,

there seemed to be no basis for estimating any discernible

effects of adoption of a new COBOL standard. They are noted in

this analysis because they fill out the set of impact elements

that should generally be considered in the cost-benefit

evaluation of a high level language standard.

3.4 Quantitative Impacts

Given the limitations of the data and process models that

are available to describe the application software life cycle,

our formulations will attempt to reflect only a rough,

first-order measurement of the impacts. Such secondary effects

as interest on cost or benefits as distributed over time would be

far less in magnitude than the margin of uncertainty about the

primary estimates and so would add little to the analysis.
CAM fa CO Eh < <

OQ 2 W Eh <J W

05

W

DO fa CO O

dJ CD 0) dJ

4-1 4-1 4J 4-1 <0 CO 03 fd E E E E

•H •H •H •H i ,—

4-> 4J 4J 4-1 CM CM

to CO CO co 00 00

d> <u o <u 1 U

U 4-> 4J 4-> -l-> CO CO

CO CO CO co

O

U

O CD <u 0> fa fa

OQ OQ OQ OQ '—

1—

uM

EhCOH2

dPin

dP dP dP O CO o

«—I VO

dP dP dP dP dP m m o o o

CM r- <Ti o m o o o • • • • • OV f-H o o o H ro OMN o

VO

CM

CM

CO

ov

Eh

faO

EhCO

fa

>Hfa

fa

fa

—

M fa

fa

QO

EH 2

CO

w

dPOdP dP dP in iH O

r~

•'* o o r* o

dP dP dP dP dP o m in o o r" oo ^ o

r-i^<r«-av i—i cm co oo o

co voCM

CO

l-l o

-uu

fd faT>c

fd

co

V-l <D

4-1 d)e

(0

l-l (0 fa

4-1 o

03aeM

VOI CO

4-> •H

jQH

x:xw

COCO

fa

fa

05

fa

Eh

fa<

fa

Eh

faM

05U

CO

faa

fao

CQ2

>HCO

00 CM 00 o o

dP dP dP dP dP dP dP dP dP • • • • • in CM in O O O in O O in in 00 o o • 00 CM vo 00 rH CM r- vo o o CO vo

CM•H

r-H CM CO 'd' in rH CM CO in

X II II ll II

n

n II ll ll II

u l-l l-l 00 CO CO co CO to CO CO CO co CO fd 0 0 1 14

d> 4-1 4-> fa d>

4-1 cn >i

OO

O

X 0 c fd fd to m -i-i •H U 14-1 4-4 E o 0

dP co o <d

u 3 a CO CO i-i

x • • CT* cn cn 0 4J

O

u 4J co

C c 0 4-> -H 1 #H 0 CO d) •H •H IH £ a, 4-j 4-> l-l u > > a ts <u <d d) O •H 3 <T5 fd <d c U E rH -U

(0 44 4J co co cn -u o CO 0 <d cd vw fd C l-l -H 3 4-> 3 1-4 to <u cn <d •H (D 4J CO 3 c C

(l)

U 14-1 c o 4-> > O <d 0 <d c >1

O <u •H c CO c c d> •H E 0 (d C E X E <d •H 0 3 O' n 0 4J •H TJ

CCS E oo E c X

O -n

C 0 4J (d <U CO \ 4J <0 1 id <y CD C -H u r—

CJI 14 CO Du u fa M 4J d) 0 4J dJ co <d d) d)

<v tnO cn c 4-4 JQ

O ns 4-4

r

—

c i-i > c O 0 OQ 0 •H 0 T3 0 XI rd <u c •H o u O u fd 0 C (fa •H 1-4 > 0 rH < cuu fa 2 dP 4JH 3 dP 4-> 4-J < o

co fa fa fa CO fa fa co co U CO U < fa 2 2 Eh 2

Average

automatic -

630-

[FCSC-82]

conversion

rate

(lines/day)
Page 21

3.4.1 Program Development -

The impact on the program development process is expected to

be positive; that is, the new features are expected to save

programmer time when coding and interpreting specifications.

However, given typical settings in which either slack time or

overtime is present, the productivity gains will often be

invisible. The productivity gains are an opportunity benefit

which may not necessarily be realizable.

The proposed revised Standard COBOL features which have the

potential to enhance programmer productivity include the

following:

1. Nested programs provide a facility for segmenting large

programs into smaller logical units. This should

improve both the reliability of these programs, since

access to the data in the program can be controlled, and

also their maintainability, since such programs are

easier to comprehend.

2. Scope delimiters assist in the generation of structured

code. While structured programming is possible within

COBOL-74, there are a number of anomalous cases where

the structuring has to be done using some artificial

means, such as PERFORM, because the ability to group

statements directly is not present. The delimiters will

make the coding smoother and less error-prone.

3. Reference modification allows the programmer to access

any part (substring) of a character field without having

to re-define the item. This is a very important

capability in string manipulation, which can otherwise

be clumsy and error-prone. This capability exists in

many high level languages (including FORTRAN 77)

,

but

not in COBOL-74.

4. EVALUATE statement incorporates a well-known construct

from structured programming practices, the multi-way

conditional. In COBOL-74, the only reasonable way to

handle such logic is with the GO TO. . .DEPENDING ON

statement, which has all the usual problems associated

with use of the GO TO.

5. Other constructs which should prove useful in clearing

up previously awkward aspects of COBOL are the ability

to: PERFORM routines in-line, set up tables with more

than three dimensions, accept as well as generate

numbers in edited form, and INITIALIZE the values in

tables.

Of the above, we were able to search the sample programs for

programming practices in which features (3) and (4) could have

been used and would have saved time for the programmer. For
Page 22

feature (3)

we searched for data items defined as PIC X (one

character only) with an OCCURS clause. For feature (4)we

searched for GO TO. . .DEPENDING ON. In our sample, roughly 22% of

the programs could have employed feature (3) and 5% could have

used feature (4)

Feature (1) will be especially useful for organizing large

programs. Exhibit 3-3 shows that programs of size greater than

1500 lines of source code account for approximately 65% of all

the lines of code (even though they constitute only 25% of all

programs)

We note that all COBOL programs can make use of feature (2)

Moreover, in the interviews conducted with representatives of the

various Federal agencies, this enhancement was the one most often

cited as potentially improving programming practice.

Thus, we anticipate that the enhancements to COBOL will

apply to some degree to virtually all programs in the Federal

inventory. For a considerable percentage of the code, the effect

will be quite significant.

The basic equation used to estimate the impact of the

revised standard on the development of new COBOL programs is

given below:

Program

Development

Impact

Where:

i =

NDP =

PAS =

CSP =

PDT =

PPM =

PSF =

10

= \~ [ (NDP) (PAS) (CSP) (PDT) (PPM) ] x [ (PSF) (AF) ( i )

/_

i=l

years; 1 , . . .

10

Number of programmer staff-years

Programmer annual salary

% of programmers working on COBOL programs

% of programmers in program development

% of ADP staff time coding

Programming savings factor

AF Acceptance factor of the revised Standard COBOL
Page 23

AF and PSF have been assigned values of 10% per year and 5%,

respectively, and are shown in Exhibit 3-6.

Applying the most likely values to the above parameters from

Exhibits 3-1 and 3-6, yields

10

Program

Development = \ [

( 118 , 000) ($27 , 800) (0 . 5) (0 . 4) (0 . 2) ] x Impact /_ [ (0.05) (0.1) (i) ] i=l

= $36,100,000 (in 1983 constant dollars for ten years and

rounded to the nearest $100,000)

3.4.2 Program Maintenance -

Program maintenance concerns those activities involving

correcting, perfecting and adapting existing application

software, and currently represents 50-70% of the program life

cycle costs [BOEH-81] , [GAO-81b] , [LISW-81]

.

The principal way in which the proposed changes to standard

COBOL would impact on the maintenance function is by increasing

the under standability of COBOL programs, and by reducing the

error-prone features of COBOL-74. The enhancements to the

language cited above under Program Development apply strongly to

Program Maintenance also, since they make it easier to read code

as well as to write it. Many of the proposed 50 incompatibility

changes are intended to eliminate or clarify certain error-prone

or ambiguous features of the current COBOL standard.

Theoretically, the proposed changes (enhancements and

incompatibilities) can 1) reduce the incidence of programming

errors and thus reduce subsequent corrective efforts, 2) enhance

the processing performance of a program and reduce subsequent

perfective efforts, and 3) enable a program to be more easily

adapted to other ADP environments or to accommodate program

changes. Mitigating against any near-term, significant impacts,

however, are the staff slack and overtime absorbing conditions

noted in the productivity discussion, and the fact that the vast

majority of maintenance is for a large inventory of existing

programs that will likely be converted at a rather slow pace.

To the extent that one can quantify program maintenance

impacts attributable to the proposed changes, they are most

likely to be found in an opportunity cost argument for freeing up

staff resources. A rough approximation to these potential

savings is given by the equation below:
Page 24

10

Program

Maintenance

Impact

= \ [ (NDP) (PAS) (CSP) (PMT) ] x [ (MSF) (AF) ( i )

]

Where NDP, PAS, CSP, and AF are the same as in

the previous equation,

PMT = % of programmers in program maintenance

MSF = Maintenance savings factor

MSF is given a most likely value of 1%. We note that this

formulation assumes that maintenance savings will accrue for only

those programs that utilize the proposed new features, which is

up to 50% in year 5 for the value chosen for AF.

Applying the values for the parameters from Exhibits 3-1 and

3-6, yields:

3.4.3 Program Conversion -

Software conversion is the transformation, without

functional change, of computer programs and data elements to a new hardware or software processing environment. The greater the

degree of incompatibility between the source and target systems

and setting, the more difficult the conversion.

Clearly, there will be an extra cost associated with moving

programs from a COBOL-74 compiler to a "COBOL-8x" (this is the

name sometimes used to refer to the proposed new standard)

compiler insofar as there are incompatibilities between the two.

This cost is the object of the quantitative analysis. It is also

true, however, that in those cases involving the definition by

the proposed revision of features which had been ambiguous or

implementation-defined, there will be an associated benefit.

This is because future conversions within the COBOL-8x standard

will not be vulnerable to different implementation of these

features.

10

Program

Maintenance = Impact

\ [ (118,000) ($27,800) (0.5) (0.6) ] x

; [ (0.01) (0.1) (i)

]

$54,100,00 (in 1983 constant dollars for ten years

and rounded to the nearest $100,000)
Exhibit 3-7 Complexity Classes

(Please see Appendix B for a description of the

incompatibilities, by number.)

1 . Reprogramming: Software is totally

system capability lacking in

Reprogramming involves redeveloping

application logic because the

fundamental to the initial design.

dependent on a source

the target environment,

extensive portions of the

absent capability is

Incompatibilities: None.

2.

Major program logic modification: Some of the code is

sensitive to the source hardware or operating system, and

equivalent features are lacking in the target environment.

Such logic modification depends on either familiarity with

the application or system software, or extensive

documentation.

Incompatibilities: 7, 11, 20, 22, 29, 41, 42, 43

3.

Minor program logic modification: Required changes depend on

other portions of the code being changed first and a multi-pass automatic translator is not available. While the

changes require programming skill, they do not require a knowledge of the functions performed by the software.

Incompatibilities: 4, 5, 9, 10, 12, 13, 15, 17, 18, 19, 23,

24, 25, 26, 27, 28, 32, 33, 34, 35, 36, 40, 45, 46, 47, 49,

50, 51, 54

4.

Simple syntax translation: This class typically involves

translation between different dialects of the same high-level

language. A technician can prepare and submit translator

jobs without knowledge of programming or the program being

converted.

Incompatibilities: 1, 2, 3, 6, 8, 14, 16, 21, 30, 31, 37,

38, 39, 44, 48, 52, 53, 55

5. Software transference

This class comprises software which

does not require any translation, but only a simple transfer

from source to target environment and possibly some

recompiling and relinking. Translation is not necessary

because the source and target operating systems, compilers,

character sets, and collating sequences are basically

identical

.

Incompatibilities: None.
Page 26

Programs may be brought into conformance with C0B0L-8x in

the following ways:

1. recoding for the sole purpose of conforming to the new

standard

2. recoding in conjunction with a system conversion to a new host system

3. recoding in conjunction with normal software maintenance

requiring re-compilation

4. reprogramming to meet new functional requirements of the

application

In assessing the impact of the incompatibilities, it is

useful to consider the Federal COBOL inventory as a whole, and to

ask how many of these programs will eventually be converted to

C0B0L-8x (as opposed simply to being left &s is until no longer

needed), and in which of the four ways above this will occur.

The list above is ordered from greatest impact per program to

least impact. At one extreme, if a program is converted purely

for the sake of conformance, then the entire cost of conversion

is attributable to the adoption of the new standard. At the

other extreme, if a program is completely re-designed anyway,

there is no measurable additional cost in seeing that it conform

to the standard. Midway between these cases would be bringing a program into conformance in conjunction with some other form of

updating, be that conversion or maintenance. While there is some

extra effort involved, much of the conversion overhead (e.g.,

re-compilation, re-testing) is "free," in that it would be done

even if the two versions of the standard were completely

compatible. It is worth recalling that programs are recompiled

rather frequently (at least once a year) for routine maintenance,

and so there is plenty of opportunity for recoding in category 3.

The cost impact is the additional effort expended in each of

the above categories. Based on interviews with Federal agencies,

and also on a review of the transition process from COBOL-68 to

COBOL-74, we conclude that very few, if any, conversions will be

done merely for the sake of conformance. This has never been the

practice in the past. Moreover, the introduction of such a practice is neither required nor envisaged by existing or planned

FIPS for high level programming languages. This policy is stated

explicitly in the three most recently issued FIPS for programming

languages (FIPS 21-1 COBOL, FIPS 68 Minimal BASIC and FIPS 69

FORTRAN) wherein it is noted that: "It is not intended that

existing programs be rewritten solely for the purpose of

conforming to the standard."

Also, the previous experience in making the transition from

COBOL-68 to COBOL-74 indicates that installations will continue

to maintain the compiler for the previous version of the standard

for a considerable time after introduction of the new version.
Page 27

We conclude, then, that the cost of achieving conformance in

categories 1 and 4 is negligible, because virtually no conversion

will be done in category 1 and there is no impact on conversion

in category 4.

Measurable costs, then, are confined to categories 2 and 3,

which we will treat together. The key questions are how many

conversions will be done this way (as opposed to category 4 or

not being done at all) , and how much extra effort will be

introduced by the incompatibilities.

The first question, the percentage of programs to be

converted, may be approached by noting some of the

characteristics of the age of programs (see Exhibit 3-3) . The

statistics on age allow us to formulate only a rough guess as to

the pattern of longevity for the current Federal inventory. Note

that the statistics are for the age of existing programs. This

age distribution would directly reflect longevity only if we

assumed that COBOL programs were being created at a constant rate

over the last 15 years or so - clearly not the case.

Nonetheless, almost any reasonable model one can develop which

assumes an average age of six years for Federal COBOL programs

will yield a result no greater than 70-75% for the share of

programs which will be converted to COBOL-8x over the next ten

years.

For example, let us consider a simple model wherein a given

agency decides to adopt the COBOL-8x standard in the following

way:

1. The conversion will take place over a two-year period,

during which both a COBOL-8x compiler and the current

compiler are available.

2. Conversion to the new standard will be done in

conjunction with normal maintenance.

3. Existing programs will continue to "die" at the normal

rate of 15% per year (equivalent to exponential

distribution, with average age equal to six years)

4. New programs will be written to conform to the COBOL-8x

standard.

Such a model yields a result of 72% of existing code

undergoing conversion. Of course this model is highly

susceptible to optimization. For instance, the death rate for

programs could be accelerated as the normal weighting factors

affecting the decision to patch or re-write a given program are

tipped in favor of re-writing. In anticipation of the

conversion, management guidelines could greatly reduce the

incompatibility in new code produced .in the year or two preceding

the transition period (e.g., no use of ENTER, the new reserved

words) . Of course this code could not take advantage of the new
Page 28

features of C0B0L-8x, but it would be compatible nonetheless. Or

the transition period could be stretched out to three years;

this alone would reduce the proportion to 61%.

Next, we must consider the degree of extra effort entailed

by the incompatibilities. As part of the effort to develop a model to quantify the conversion cost impacts, we reviewed the

conversion models and analyses in [BOEH-81] , [DITT-80]

,

[OLIV-79] , [FCSC-81] and [FCSC-82] . All these models have

similar assumptions and basic structures. They use adaptation or

adjustment factors, subjective/experience-based impacts, classes

of conversion complexity, cost-per-line of code, and various

conversion task work breakdowns. For this analysis, we* decided

to utilize various parts of the Federal Conversion Software

Center model [FCSC-82] . Its formulation is exclusively oriented

to and based on Federal ADP systems. Also it reflects [LIV-79]

and [FCSC-81] , and it provides reasonable definitions of the

conversion complexity classes and of average conversion

cost-per-line of code by class. Through the use of this model,

we can express in a precise way the intuitively natural notion

that the costliness of a given incompatibility will depend

strongly on how frequently the incompatibility is used (as

measured by the sample) and how complex a conversion it entails

(as reflected in the assignment of incompatibilities to

complexity classes, see below)

.

The basic equation for the cost of source code conversion in

the FCSC model is:

5

SD \ SSDs

s=l

Where:

s = Complexity class (1 = most complex, 5 = least)

SSDs = Staff-days for required for class s.

SD = Total staff-day cost

The SSD for each s is, in turn, evaluated by:

(LOCs) ( 1-Ts

)

(LOCs) (Ts)

SSDs + MCPRs ACPR

Where

:

LOCs = Lines of code to be converted in class s
Page 29

Ts = Percentage (expressed as a fraction) of lines

of code capable of being correctly translated

automatically for class s. MCPRs = Average manual conversion productivity rate

for class s ACPR = Average automatic conversion productivity rate

Exhibit 3-7 describes the complexity classes. The

assignment of incompatibilities to these classes is based on a technical review of the current and proposed standards, and also

on information obtained from the various donor agencies regarding

the way in which they use certain features. The only parameter

which will be affected by the incompatibilities is LOCs. By

increasing the complexity of a conversion, an incompatibility

will increase LOCs for more complex classes and decrease it

correspondingly for less complex classes. It is convenient to

manipulate the above model so as to isolate just this crucial

piece of information:

5

Incremental

Conversion = \

Impact /

s=l

Where:

BLCs = Percentage of lines of code in class s', base case

CLCs = Percentage of lines of code in class s, after impact

of incompatibilities

s-1 5

= (BLCs) (1 - FRCi) + (FRCs) ( “BLCi)

l_ /_

i=l i=s+l

Where FRCx is the percentage of all programs forced

up to class x by incompatibilities. Note that the

first term reflects the loss of programs from class

s to more complex classes, and the second term

reflects the gain from less complex classes.

TL = Total lines of code to be converted

[CLCs - BLCs] x [

( 1-Ts ) TS

+ ] x (TL)

MCPRs ACPR
Page 30

We will assign values to MCPRs, APCR, and Ts based on

cautious estimates derived from [FCSC-82] , see Exhibit 3-6.

Further, we shall assume an average salary of $27,800, as before,

and 213.2 staff-days per year, again from [FCSC-82]. This allows

us to derive a cost per line for each conversion class. Also our

model should reflect explicitly the judgment about how many lines

of code will be converted. Thus, the final form of our model

equation is:

5

Incremental

Conversion = (NCS) (NLP) (NCP) V" [CLCs - BLCs] (CCLs)

Impact /

s=l

Where:

BLCs and CLCs are as before,

NCS = Fraction of COBOL programs which will undergo

conversion as in category 2 or 3, described above.

NLP = Average number of lines per COBOL program

NCP = Number of COBOL programs in Federal inventory

CCLs = Conversion cost per line for class s

(1 - Ts) Ts

= [ + ] (PAS) / (SDY)

MCPRs ACPR

(Where SDY = 213.2 staff-days per staff-year, and

PAS = $27,800 programmer annual salary)

Personnel costs are an appropriate basis for classes 1-4

because they are labor-intensive activities. They are a rough

but reasonable surrogate for machine time and/or amortization

rates for the 5th class, because those costs per line are so

small regardless of the cost basis.

The determination of values for BLCs can only be an

estimate. Note that as one assigns higher percentages to the

more complex classes of the base case, the cost impact decreases.

Further, the base case no doubt differs for category 2

(conversion) and category 3 (maintenance) . We arrived at base

case values (See Exhibit 3-8) based on consultation with the

Director of the Federal Conversion Support Center and members of

the Federal COBOL Task Group, a group of representatives of

Federal agencies which use COBOL extensively. The values used

represent base case estimates for conversion (as opposed to

maintenance) and so are somewhat pessimistic.
Exhibit

3-8

Cost

Analysis

of

Incompatibilities

co • c CO 0 0

•H

C

r-H o CM CO

H1 rH •H

-P i—1 • • • • • rH O -H o »—1 in CO O

<0 e 1 CM + + c a 1 0 e </> •H H rHrH

•rHE

S-l CM 0 to- • co a, in •sr CM rH CM j VO m CM O >i CM

CJ -P' 0 • • • • • rH CM u w C vo CM o o o 0 0 * H 1 1 i 1 i co II u rH •rHo E 0 0

S-l S-l a CP c 0

•H • dP dP dP dP dP TS S-l jQ o CM rH CO O T3 a 0 -H • • • • (0 \ CP S-i o rH r-~ CO C -P + CM i—i 1 -U 0

(13

W + l 0 c

XI -H c H U TS 0 i—1

T3

O

cp—- t-~ C • CO CM •H jQ 0 rH

-P -H dP dP dP dP dP S-l ID H M o CM rH r- O 3 -P o 3 -p • • • • CP 0

iJ CO CO o 1—1

r- i—1

•H

U <u -h in iw COE —- rH 0

-H S-l CP 0 -P 0 • -P —v 0 S-l CO CO Q • a, CPTS dP dP dP dP dP CP

co o a) to o CM co

O • c o a s-i o to • • • •H o

PS Oj S-i (C3

O vo CO

C xs o

Eli 0 "—1

CM in 0 c o •rH 3 o — rH 0 in

rH

p CM •H 0 —. E mh V|H CO • (0 X! u> 0 0 O -H ~

0 dP

CO S-l CO

O

U o 4J dP dP dP dP dP <Ti 3 q co co o O O uo in • 0

CQ (0 -H CM r- r-- o c

CO T3 rH 0 o 1 X! XI • • 0

>1 -P co -P — o 0

•H CO 0 X! X a 0 E -P rH CO M o a CO 0 E (C3 1-1

CM CO in -P

a 0 i—1 0 E u u M
Page 32

Values for FRCs were taken from an analysis of the sample

programs. We assigned each of the incompatibilities to one of

the five complexity classes and then, by successively masking off

the effects of the incompatibilities for each class, (from less

to most complex) determined the percentage of programs which

would be forced to each of the classes. See Exhibit 3-7 for the

assignment of incompatibilities to complexity classes. We then

assumed that this "forcing up" was independent of, and therefore

uniformly distributed over, the base case. This assumption is

expressed in the derivation for CLCs, above. The entire

conversion cost analysis is summarized in Exhibit 3-8. The

result is a total cost of $17.9 million.

There were a few incompatibilities which could not be

detected syntactically. A brief discussion of the more important

of these is given to complete the impact analysis for conversion.

1. C0B0L-8x specifies the semantics for the case in which

there is no next executable statement. Presumably, very

few programs rely on the implementor-defined semantics

(because it is undefined in COBOL-74) for this

situation. Since the semantics simply involves where

flow of control will go next, it should be relatively

easy to change those programs which are affected.

Diagnosing the change in behavior may be a significant

problem.

2. C0B0L-8x allows reading past end of file. Although most

programs use AT END, there should be very few, if any,

whose algorithm allows reading past end of file. It is

easy enough to install a switch to detect this

situation, if need be. The major effect (whether for

good or ill, an open question) will be in program

development, not conversion.

3. C0B0L-8x specifies that STOP RUN closes all files. We

assume that few programs rely on the implementor-defined

semantics of leaving files unclosed. The only effect of

this condition is necessarily outside the program, and

it is probable that whatever effect is being achieved

can be duplicated with job control statements.

3.5 Qualitative Impacts

Several types of impacts which may result from the

implementation of the proposed changes to COBOL-74 could not be

quantified in this analysis. Lack of adequate data and the

intangible characteristics of the impact are the principal

reasons. These qualitative impacts are worth noting because they

are legitimate considerations in a pre- or post- implementation

assessment of a FIPS.
Page 33

The qualitative impact discussions are presented in their

order of appearance in Exhibit 3-5. Each impact is described in

terms of its basic characteristics and whether its effects are

expected to be positive or negative.

3.5.1 Training -

In this analysis, training costs are the expenditure of

resources to teach a staff the new revised Standard COBOL, over

and above the teaching costs expected in the Base Case. For the

study horizon this impact will be negative; that is, additional

costs above the base case level are expected.

Training expenses typically consist of the cost of 1)

instructor time and course preparation, 2) facilities, materials,

workshops, and 3) trainee time during the course.

For this formulation, the first two items are judged to be

insensitive to the proposed changes, and the third item, trainee

time, will be used as the surrogate parameter for the training

impact. Further, we make the following assumptions:

1. All programmers (including those with prior experience)

reporting to a new job require a training course. The

revised Standard and Base Case costs for these

programmers are essentially the same.

2. Recurring career enhancement training is essentially the

same for the revised Standard and Base Case settings.

The only significant additional cost, therefore, will be

when programming staff must be trained "out of sequence," i.e.,

earlier than in the base case because of a conversion to

C0B0L-8x. We do not expect this impact to be very great, and

almost certainly it will be an order of magnitude lower than the

quantitatively evaluated impacts discussed above.

3.5.2 Processing Efficiency -

The premise underlying this impact is that, on the average,

in a setting where there are many programmers of varying

expertise, a high order language such as COBOL can permit

efficient use of the computer system resources. The changes

proposed are expected to enhance the processing efficiency of

programs in COBOL, and the overall effect for this impact area

should be positive.

Another possible effect, which would be negative, is the

cost of maintaining an extra compiler while undergoing transition

to C0B0L-8x. Our study survey showed, however, that
Page 34

installations typically support at least two COBOL compilers

anyway. There will be very little, if any, detectible increase

in operating costs traceable to adoption of a new standard. In

any event, such a cost would be borne by a compiler for any new

standard, even one that was fully upward compatible.

3.5.3

Functional Enhancement -

Using a high order language such as COBOL often leads to

improvements in the application functions. Frequently fewer

programs are needed, data collection is simplified, and manual

operations can be eliminated.

To the extent the proposed changes can improve the accuracy

of reports by reducing errors and awkward operations, there can

be a contribution to the functions supported by COBOL programs

that can use these changes. We expect that these impacts will be

positive but indirect and slight.

3.5.4

Requirements Analysis -

The process of specifying functional requirements, and then

translating those requirements into program specifications for

coding, is affected directly by the choice of programming

language. To the extent users can communicate their needs fully

and verify the programmed results easily, the requirements

analysis process becomes more efficient and effective. All

procedural software languages are artificial relative to English.

The likelihood of the solution being incorrect, or even of the

wrong problem being formulated, increases when it is more

difficult for the user and programmer to communicate about the

requirements. To the extent that a programmer can express the

needs of the user with the help of constructs directly available

in COBOL, the communication process between the two is enhanced.

The proposed changes are expected to reinforce this process

of better communications about the application requirements

analysis by reducing the ambiguous and error-prone features of

the existing COBOL standard, as well as by introduction of the

new features mentioned earlier. This impact will be positive but

indirect and slight.

3.5.5

Program Life Span -

A program with a longer effective life span is preferable to

one with a shorter life, under the same operating conditions.

The benefits accrue from reduced applications programming, and

also, if reusable code modules are constructed, from reduced

corrective maintenance costs.
Page 35

The proposed changes should extend the useful life of COBOL

programs in two ways. First, by defining previously

vendor-dependent features of the language, programs will become

more portable, and hence less likely to be discarded when

converting to a new hardware system. Second, there are various

new language features which enhance the modularity of the

language. Modularized programs are more easily maintained; a radical change in one part does not affect the rest of the code

and so there is no need to discard the entire structure and

re-write from scratch. This impact will be positive but slight,

as COBOL programs are already rather long-lived.

3.5.6 Programmer Transferability -

Since the late 1960"'s, the pool of personnel interested and

trained in COBOL has grown dramatically. A greater supply of

personnel already familiar with the language in use reduces

training and learning time and makes it easier to recruit staff

to use COBOL. Given the turnover ratio in the military and

civilian sectors, enhanced programmer transferability is clearly

a benefit to Federal agencies that use COBOL.

As mentioned earlier, there are many cases where the

proposed revision clarifies or defines language features which

were ambiguous or implementor-defined in COBOL-74. Thus, the

proposed changes will inprove the ability of programmers to

migrate from one implementation to another. Of the qualitative

effects of the proposed changes, this impact area is the most

significant.

3.6 Sensitivity Analysis

The principal objective of a sensitivity analysis is to

assess the degree of variation in the cost/benefit impact

estimates generated by changes in the study assumptions, and to

provide insight into the validity of the study findings (see

Exhibit 3-9 for a summary) . Therefore, we will discuss in

greater depth those assumptions which are most subject to doubt

and which affect the outcome most strongly.

3.6.1 Benefits -

The benefits, as is typically the case for standards, are

broad but shallow. Estimating the breadth (i.e., scope) of the

benefit is relatively simple: clearly the impact extends

throughout the use of COBOL in - the Federal government. The

difficulty is in arriving at a reasonable estimate for the depth:

how much good will the new standard do in an "average" Federal

agency? We have tried to be cautious in our estimates of the
Page 36

programming savings factor (PSF) and maintenance savings factor

(MSF) . The less precise of these is probably MSF. If we assume

that MSF is 2%, instead of 1%, the maintenance benefit increases

by $54 million. Such a value is well within reason, but cannot

be demonstrated with the available data.

The only point to be made beyond this is that the standard,

per se, can offer only a potential for savings in program

development and maintenance. The real izat ion of that potential

depends on several factors, but especially on good DP management

practices.

3.6.2 Cost -

We will now examine those assumptions upon which depends the

most likely cost estimate of $17.9 million.

The base case distribution for conversions (BLCs) is not

directly supported by any available data (see Exhibit 3-8) . If

we assume that conformance to C0B0L-8x will be accomplished in

conjunction with normal Software maintenance, rather than

conversion, we might plausibly conclude that the base case values

are 0%, 0%, 45%, 50%, and 5%, i.e. there will be more class 3

complexity because maintenance may well involve functional

changes, whereas conversion, by definition, does not. Under this

assumption, the cost estimate becomes $13.2 million.

Clearly, the bulk of the cost stems from those

incompatibilities which both occur frequently and force a class 3

modification. There are four of these that deserve some

individual comment:

1. Deleting MEMORY SIZE from the standard

2. Deleting ENTER from the standard

3. Defining the effect of EXIT PROGRAM on PERFORMS

4. Defining the order of evaluation of subscripts within

PERFORMS

Items 3 and 4 cannot reasonably be changed back to the

original specification of COBOL-74. They simply define the

semantics of two cases which were not described in COBOL-74.

For item number 1, the effect was completely dependent on

the implementation in any event; almost all modern systems

accept such information as part of their system control language.

For item number 2, it is technically feasible to keep the

specifications of COBOL-74. If this were done the cost estimate

would shrink to $11.3 million. There would also be, however, an
Page 37

adverse effect on the benefit side. ENTER was deleted precisely

because it encourages the development of code which is

error-prone and difficult to maintain. It would take only a 7%

reduction of the benefits to cancel out the $6.6 million cost

savings.

It is worth noting that in all four cases above, programs

depending on the COBOL-74 specification were not guaranteed to be

portable by that specification; all four changes are examples of

taking aspects of the COBOL-74 standard which were ill-defined

(purposely or not) to begin with, and either deleting the feature

outright, or simply defining its effect. In none of these cases

is a truly well-defined portable feature being affected.

The final issue is what policy Federal agencies will adopt

governing coding practices in the years leading up to the actual

transition to a C0B0L-8x implementation. We have somewhat

pessimistically assumed that, as new code replaces discarded

programs, it will have the same degree of incompatibility. If,

on the other hand, new code under development were monitored for

conformance to C0B0L-8x, then the effective percentage of code

needing actually to undergo conversion (parameter NCS) would

shrink from 70% to 50% within a few years. A figure of 50%

implies conversion costs of $12.8 million.

Exhibit 3-9 Sensitivity Analysis

Assume Assume

MSF = 1% MSF = 2%

most likely

assumptions

Benefit: 90.2 144.3

Cost: -17.9 -17.9

Net: 72.3 126.4

base case

distribution:

0,0,45,50,5

Benefit: 90.2 144.3

Cost: -13.2 -13.2

Net: 77.0 131.1

assume ENTER

unchanged, 10%

benefit loss

Benefit: 81.2 129.9

Cost: -11.3 -11.3

Net: 69.9 118.6

NCS =50% Benefit: 90.2 144.3

Cost: -12.8 -12.8

Net: 77.4 , 131.5

(All figures in $ millions)
Page 38

4.0 FINDINGS

4.1 Interpretation

This study shows that the effect of revising the COBOL

standard as proposed should not be dramatic, either for good or

ill (see Exhibit 4-1) . There is a real opportunity to improve

certain features of the language which should not be ignored, but

the changes will hardly revolutionize COBOL programming in the

Federal sector. At the same time, there will be some problems

created by incompatibility, but these are not unusual, either in

kind or in degree. Nor should it be surprising that the effect

is relatively small; the proposed revision is just that: a revision of an existing standard - and not that markedly

different from it.

It is important to put the projected costs and benefits into

perspective. An effect of $100 million, spread out over ten

years, represents 0.3% of the salaries (unadjusted) of Federal

programmers over that same period. Also, the incompatibility

problem in particular needs to be addressed. There was a virtual

consensus among the ADP personnel we interviewed that modifying

source code was among the easier aspects of conversion. They had

experienced far more difficulty with conversion of data and of

job control code. Some agencies actually had to write their own

I/O routines, rather than use those of the new system, because of

data incompatibility between the old and new systems. When asked

what their biggest problem was, most answered, "the lack of

documentation." One interviewee characterized this as the problem

of "portability of programs between programmers."

4.2

Recommendations

4.2.1 Incompatibility -

There is no need to improve compatibility between the

current and proposed versions of COBOL. While there are

theoretical problems, the way in which COBOL is actually used in

the Federal government renders them relatively minor. The

introduction of any further incompatibilities, however, should be

subject to careful evaluation, to ensure that their impact is no

more adverse than those considered in this study.

It is important that Federal ADP managers be alerted to the

advent of COBOL-8x, and its subsequent impact. In particular,

ICST will provide guidance concerning the monitoring of new code

under development. Such simple steps as avoiding the use of

ENTER will have a large payoff later on when agencies undergo

conversion to COBOL-8x.

Also, it is important that automatic conversion be

accessible to Federal users. When new compilers start reaching

the market, concerned Federal agencies should determine whether
Page 39

automated translators are available. If not, they should

seriously consider co-sponsoring the production of such a software tool.

4.2.2 Education -

ICST will make a vigorous effort to see that the Federal

government reaps the full benefit of a new COBOL standard. The

new features will help Federal users only if they are known and

understood by both programmers and managers. ICST will promote

correct use of the new features through a variety of media:

guidelines, workshops, and the Federal COBOL Task Group.

4.2.3 Timing -

The benefits of revising the COBOL standard are largely

associated with the COBOL programs yet to be written. The costs

are associated with those which already exist and depend on

features unique to COBOL-74. Therefore, the sooner the standard

becomes known and adopted, the better. The problems of

incompatibility, real as they are, do not justify delaying the

ongoing maintenance and improvement of the COBOL language.
Page 40

Exhibit 4-1 Summary of Impacts for the Proposed COBOL Standard

(Including All Incompatibility Changes Proposed)

IMPACT AREA QUANTITATIVE (1) QUALITATIVE

Program Development $36,100,000

Program Maintenance $54,100,000

Program Conversion ($17,900,000)

Training - Negative, Slight

Processing Efficiency - Positive, Slight

Functional Enhancement - Positive

,

Slight

Requirements Analysis - Positive, Slight

Program Life Cycle - Positive

,

Slight

Programmer Transferability Positive, Moderate

NET TOTAL $72,300,000 Positive, Slight

(1) Constant 1983 dollars, summed over 1984-1993; all figures

rounded to the nearest $100,000. Figures in parentheses

are negative.
Page 41

REFERENCES

[ANS-74

]

Technical Committee X3J4, American National Standard

programming language COBOL , ANS X3. 23-1974, ANSI,

May, 1974

[ANS-81] Technical Committee X3J4, Draft Proposed Revised

X3.23 American National Standard Programming Language

COBOL, ANS, Sep. 1981.

[BOEH-7 6a] Boehm, B. W. "Software Engineering," IEEE

Transactions on Computers, Vol. I, C. 25, No. 12,

December, 1976.

[BOEH-7 6b] Boehm, B. W. , Brown, J. R. , and Lipow, M.

"Quantitiative Evaluation of Software Quality",

Proceedings of Second International Conference on

Software Engineering, 1976.

[BOEH-81] Boehm, B. W. Software Enginering Economics, Prentice

Hall, Inc., Englewood Cliffs, New Jersey, 1981.

[BROO-75] Brooks, F. P. The Mythical Man-Month: Essays on

Software Engineering, Addison, Wesley, Reading,

Massacusetts , 1975.

[BROO-80] Brooks, R. E. "Studying Programmer Behavior

Experimentally: The Problems of Proper Methodology",

Communications of the ACM, Vol. 23, No. 4, April,

1980

[CHFS-81] Christensen, K. , Fitsos, G. P., Smith, C. P. "A

Perspective on Software Science", IBM Systems

Journal, Vol. 20, No. 4, 1981.

[CROW-79] Crowley, J. D. "The Application Development Process:

What^s Wrong with It", JDC Associates,- Walnut Creek,

California, 1979.

[CURT-80] Curtis, B. "Measurement and Experimentation in

Software Engineering", Proceedings of the IEEE, Vol.

68, No. 9, 1980

[DITT-80 ] Dittman, J. T. Transferability Factor Manual,

Veterans Administration, Columbia, MD, March 1981.

[DUBN-81]

[DEUT-75]

Dubnow, A. "A Point-by-Point Rebuke of Revision

Efforts on COBOL Standards", Data Management,

December 1981.

Deutsch, D., et al. An Assessment of the NBS Project

for Federal Standardization of the COBOL Computer

Programming Language, NBS Working Note, June 1975.

[DEUT-75]
Page 42

[ DEUT-76

]

[FCSC-81]

[FCSC-82]

[FIOR-78]

[GAO-77]

[GAO-80]

[GA0-81a]

[GA0-81b]

[GAO-82]

[GRAY-79]

[GRAY-81]

[JONE-77]

Deutsch, D. Approval of Federal Government COBOL

Standards and Software Management: Survey Results,

NBS IR 76-1100, NBS, August 1976.

FCSC, Review and Analysis of Conversion

Cost-Estimating Techniques , GSA/FCSC-81/001 , Federal

Conversion Support Center, Falls Church, Virginia,

April 1981.

FCSC, Federal Conversion Support Center Conversion

Cost Model (Version 2) , GSA, Office of Software

Development, Report No. GSA/FCSC-82/001 , Falls

Church, Virginia, June 1, 1982.

Fiorello, M. and Jaffin, S. Costs and Benefits of

Federal Automated Data Processing Standards

Guidelines for Analyses and Pr el iminary Estimating

Techniques, Logistics Management Institute, Wash.

,

DC, 1978.

Comptroller General, Millions in Savings Possible in

Converting Programs from one Computer to Another,

GAO, FGMSD-77-34 , September 15, 1977

Comptroller General, Continued Use of Costly

,

Outmoded Computers Tn Federal Agencies Can Be

Avoided , GAO, AFMD-81-9, December 15, 1980

Comptroller General, Government-Wide Guidel ines and

Management Assistance Center Needed to Improve ADP

Systems Development, GAO, AFMD-81-20, February 20,

1981.

Comptroller General, Federal Agencies^ Maintenance of

Computer Programs: Expensive and Undermanaged , GAO,

AFMD-81-25 , February 1981.

Comptroller General, Improving COBOL Appl ications Can

Recover Significant Computer Resources, GAO,

AFMD-82-4 , April 1, 1982.

Gray, M. G. Computers in the Federal Government

A

Compilation of Statistics - 1978 , NBS Special

Publication 500-46, Institute for Computer Sciences

and Technology, National Bureau of Standards,

Washington, DC 1979.

Gray, M. G. An Assessment and Forecast of ADP in the

Federal Government , NBS Special Publication 500-79,

Institute for Computer Sciences and Technology,

National Bureau of Standards, Washington, DC, 1981.

Jones, C. Program Quality and Prorammer Productivity , IBM, TR 62.764, San Jose, California, January 1977.
Page 43

[LISW-81]

[MANT-81]

[MOHA-81]

[MUNS-78]

[NBS-72]

[NBS-75

]

[NBS-81]

[NELS-81a]

[NELS-81b]

[OSD-81]

[OTTE-79]

[OLIV-79

]

[SHOE-80

Lientz, B. and Swanson, E. "Problems in Application

Software Maintenance", Communications of the ACM , Vol. 24, No. 11, November 1981.

Mantei, M. "The Effect of Programming Team Structures

on Programming Tasks", Communications of the ACM,

Vol. 24, No. 3, March 1981.

Mohanty, S. N. "Software Cost Estimation: Present and

Future", Software - Practice and Experience, Vol. 11,

1981.

Munson, J. B. "Software Maintainability: A Practical

Concern for Life-Cycle Costs", Proceedings of

COMP SAC , November 1978.

NBS , Common Business Oriented Language - COBOL, NBS,

FIPS Pub 21, March 15, 1972.

NBS, COBOL , NBS, FIPS PUB 21-1, December 1, 1975.

The Effects of Future Information Processing

Technology on The Federal Government ADP Situation , A. D. Little, Inc. , General Systems Group, Inc.

,

Aurora Associates, Inc., NBS GCR 81-342, NBS,

September 1981.

Nelson, D. "Letter to R. Shoor of Computer World",

Control Data Corporation, Sunnyvale, California,

February 4, 1981.

Nelson, D. "Letter to Mr. R. Widmer, TWA," Control

Data Corporation, Sunnyvale, Calif., January 27,

1981.

Office of Software Development, Software Improvement

- A Needed Process in the Federal Government , GSA,

OSD-81-102, Falls Church, Virginia, June 3, 1981.

Ottenstein, L. M. "Quantitative Estimates of

Debugging Requirements", IEEE Transactions on

Software Engineering , Vol. SE-5, 1979.

Oliver, P. , Handbook for Estimating Conversion Costs

of Large Business Programs , ADPESO, U.S. Navy,

Washington, DC, February 1979.

Shoemaker, D. Br ief Case Studies on the

Implementation of FIPS PUB 21-1 Federal Standard

COBOL and Problems Associated with ADP Systems

Programs and Data Conversions , Shoemaker

ADP/Telecommunications Standards Consultant,

Woodbridge, VA, November 1980.
Page 44

[SHOE-81] Shoemaker, D. and Aurora Assoc. , Inc. Product

Utilization Survey of the Federal Information

Processing Standards Program , Aurora Associates,

Inc., Washington, D.C., September 1981.

[STEW-81] Stewart, S. "Memorandum - Comments on Proposed ANSI

COBOL," Institute for Computer Sciences and

Technology, NBS , December 23, 1981.

[YOUR-79] Yourdon, E. The Second Structured Revolution , Yourdon, Inc., New York, 1978.
APPENDIX A

BASIC COST-BENEFIT ANALYSIS METHODOLOGY

The cost-benefit methodology is based on the 1978

preliminary guidelines for impact assessments of standards

[FIOR-78]

.

1. Specifying the Goals and Objectives for the Standard.

Identifies which ICST goal(s) and objectives ( s) the

prospective standard is expected to contribute to and

achieve, respectively.

2. Preparing the Standards Def ini tion Statement.

Summarizes all the essential information about the

standard necessary to conduct the cost-benefit analysis.

At a minimum this includes:

How the standard will be developed, used and

supported.

Essential assumptions and information for the cost

and benefit estimates submitted.

The historical data trail on the evolution of the

standard's design and development, and the

corresponding impact and cost estimates from the

beginning to the formal implementation of the

standard. The trail is provided by the

chronological sequence of updated definition

statements

.

A basis for a critical review of the standard's

objectives and a discussion on how well the proposed

design and development process will satisfy them.

Descriptions of the areas of high technological risk

and cost-benefit uncertainty.

The statement can also reference selected information in

the backup material that documents the cost and benefit

estimates. Each time a cost-benefit analysis is

prepared, a Standard Definition Statement will also be

prepared. In this way, the statement provides a readily
BASIC COST-BENEFIT ANALYSIS METHODOLOGY Page A-2

available audit trail and a basis for critical review of

the standard.

3. Defining the Base Case. Defines the status quo for

those cost-benefit impact dimensions relevant to the

standard. The Base Case can be defined for one or

several FIPS that are under consideration. The several

FIPS case would occur where the impacts from two or more

alternatives tend to overlap, and the individual impacts

are not readily distinguishable.

4. Selecting the Cost-Benefit Impact Areas. Specifies cost

and benefit impact areas relevant to the standard. A

standard will require certain costs for development,

implementation, validation and maintenance. In

addition, there are costs that can be incurred by the

Federal ADP installations that utilize the standard. On

the benefit side, a standard will typically tend to have

its major economic impacts in one of three areas:

procurement, operations, or conversion. These impact

areas and elements further delineate how a standard

contributes to the ICST goals and objectives concerned

with achieving economies in ADP procurement, operations,

and conversion. Table A-l gives the list of impact

areas

.

5. Constructing the Cost-Benef it Analysis Model

.

Provides

the appropriate model form to quantify the cost and

benefit impacts expected of the standard. The model is

used to estimate the flows of costs and benefits

attributable to the standard over time.

6. Obtaining Data. Collects the data to perform the

analysis. In addition we expect to utilize the data

from the cost-benefit analysis of selected, individual

standards

.

7. Estimating and Evaluating the Cost-Benefit. Represents

the consolidation of the qualitative and quantitative

analyses performed up to this point. The basis of the

cost-benefit analysis will be the generation of the Base

Case parameters and the computation, within specific

confidence intervals, of the effect a new standard

scenario will have on cost levels. The techniques used

to generate the figures comprising the Base Case address

the areas of: (1) level of expected resource

consumption, (2) Federal ADP installations' unit cost

for each resource, and (3) projected impact(s) of the

proposed ADP standard. To aid in this process, cost

element equations will be used. To determine the net

cost-benefit impact of a FIPS, the costs to the Federal

Government (specifically ICST) of developing and

implementing the FIPS will be defined and incorporated

into the analysis.
BASIC COST-BENEFIT ANALYSIS METHODOLOGY Page A-3

8. Presenting and Interpreting the Results. Translates the

cost-benefits attributable to the FIPS in the context of

the Federal Agencies that will likely be impacted by the

standard. This step is crucial as it specifies whether

actual budget dollars will be changed (such as in

procurement impacts) or whether the impacts are

productivity changes (such as when a resource is freed

up for other activities)

.
BASIC COST-BENEFIT ANALYSIS METHODOLOGY Page A-4

Table A1

COST-BENEFIT IMPACT ELEMENTS 100

PROCUREMENT

101 Hardware

102 Software

103 Testing

104 Planning and Analysis

105 Initial Training

106 Documentation

107 Installation

200

OPERATIONS

201 Operating

202 System Management

203 Maintenance

203.1 Hardware Maintenance

203.2 Software Maintenance

204 Programming

205 Ongoing Training

206 Facilities

207 Security Provisions

300

CONVERSION

301 Program Transfer

302 Retrofit

400

SYSTEM PERFORMANCE

401 Computer System

402 Applications Software

403 System Users

500

COMPUTER MISUSE

501 Errors and Omissions

502 Computer-related Fraud and Embezzlement

503 Privacy Intrusion

504 Alteration of Computer Records

505 Theft of Computer Information

506 Unauthorized Usage

507 Denial of Service

508 Equipment Damage
APPENDIX B

INCOMPATIBILITIES BETWEEN COBOL-74 AND COBOL-8X

Description of Incompatibilities, by Number

1. Deletion of rule providing for substitution of double

characters for a single character.

2. When figurative constant ALL literal is not associated

with another data item, its length is that of the

string, rather than one.

3. (Withdrawn) Figurative constant ALL literal cannot be

associated with a numeric or numeric edited data item.

4. (Withdrawn) The implicit description of the special

register DEBUG-ITEM has been changed.

5. MEMORY SIZE clause deleted.

6. The word ALPHABET is now required before alphabet-name

in the SPECIAL-NAMES paragraph.

7. The collating sequence for an indexed file is defined as

the native sequence in effect at file creation, not that

of the PROGRAM COLLATING SEQUENCE clause (previously

undefined)

.

8. The literal within the CURRENCY SIGN clause may not be a figurative constant.

9. The relative key data item specified in the RELATIVE KEY

phrase must not contain the PICTURE symbol "P".

10. Each file in a series of files sharing the same physical

reel of tape must be created with a uniform labelling

convention. A sort or merge file may not be specified

in the MULTIPLE FILE TAPE clause.

11. RERUN clause deleted.
INCOMPATIBILITIES BETWEEN COBOL-74 AND COBOL-8X Page B-2

12. Files for which the LINAGE clause has been specified

must not be opened in EXTEND mode.

13. When a receiving item is a variable-length data item and

contains the object of the DEPENDING ON phrase, the

maximum length of the item will be used (as opposed to

the actual current length)

.

14. Digit positions specified by PICTURE "P" will be

considered to contain zeros only in numeric operations

(as opposed to operations involving non-numeric

operands)

.

15. Evaluation of complex conditions takes place in

hierarchical order, left to right, and terminates as

soon as the truth value is determined (previously

undefined)

.

16. ALPHABETIC class condition accepts lowercase as well as

uppercase letters.

17. (Withdrawn) ALTER statement deleted.

18. CANCEL statement closes all files (previously

undefined)

.

19. CLOSE statement cannot contain both the NO REWIND phrase

and the REEL/UNIT phrase.

20. KEY phrase of the DISABLE statement deleted.

21. Subscripts within the REMAINDER clause are evaluated

after results stored in GIVING operand (previously

undef ined)

.

22. KEY phrase of the ENABLE statement deleted.

23. ENTER statement deleted.

24. When there is no next executable statement in a called

program, an implicit EXIT PROGRAM is executed

(previously undefined)

.

25. EXIT PROGRAM closes out all PERFORMS in the called

program (previously undefined)

.

26. Order of evaluation of subscripts within INSPECT

statement is defined (previously undefined)

.

27. No two files in a MERGE statement may be specified in

the SAME AREA or SAME SORT-MERGE AREA clause. The only

files in a MERGE statement that can be specified in the

SAME RECORD AREA clause are those in the GIVING phrase.
INCOMPATIBILITIES BETWEEN COBOL-74 AND COBOL-8X Page B-3

28. (Withdrawn) The 1-0 and EXTEND phrase of OPEN cause

non-existing files to be created.

29. REVERSED phrase of OPEN deleted.

30. Order of initialization of multiple VARYING identifiers

in PERFORM is specified (previously undefined)

.

31. Within the VARYING. . .AFTER phrase of the PERFORM

statement, identifier-2 (the higher level control

variable) is augmented before identifier-5 (the lower

level control variable) is set (as opposed to the

reverse order)

.

32. Execution of READ after the at-end condition occurs is

now permitted.

33. The INTO phrase of READ cannot be specified unless: (a)

the data item of the INTO phrase and all records

associated with the file are group items or

alphanumeric, or (b) there is only one record

description associated with the file.

34. If a RECEIVE gets a partial message, the next RECEIVE

must specify the fully qualified queue structure to get

the rest of the message (previously undefined)

.

35. The INTO phrase of RETURN cannot be specified unless:

(a) the data item of the INTO phrase and all records

associated with the file are group items or

alphanumeric, or (b) there is only one record

description associated with the file.

36. STOP RUN closes all files (previously undefined)

.

37. Order of evaluation of subscripts within STRING

statement is defined (previously undefined)

.

38. In the UNSTRING statement, subscripts of delimiting

identifiers are evaluated once, immediately before

examination of the sending field for delimiters (as

opposed to repeated evaluation)

.

39. The WRITE statement must not contain both the ADVANCING

PAGE and END-OF-PAGE phrases.

40. (Withdrawn) Independent segments deleted.

41. Concept of current record pointer changed to file

position indicator.

42. For relative or indexed files, an OPEN I-O, followed by

WRITE statements, followed by READ NEXT causes the READ

to access the first currently existing record, not

whichever record was first at the time of the OPEN.
INCOMPATIBILITIES BETWEEN COBOL-74 AND COBOL-8X Page B-4

43.

44.

45.

46.

47.

48.

49.

50.

51.

52.

53.

54.

If an alternate key of reference is changed by REWRITE

to a value between the current and next value in the

file, a subsequent READ NEXT will obtain that same

record

The following reserved words have been added:

ALPHABET

ALPHANUMERIC

BINARY

CONTENT

DAY-OF-WEEK

END-COMPUTE

END-EVALUATE

END-PERFORM

END -RETURN

END-START

END-UNSTRING

EXTERNAL

INITIALIZE

OTHER

PURGE

STANDARD-2

TRUE

ALPHABETIC -LOWER

ALPHANUMERIC-EDITED

CLASS

CONTINUE

END-ADD

END-DELETE

END-IF

END-READ

END-REWRITE

END-STRING

END-WRITE

FALSE

NUMERIC-EDITED

PACKED-DECIMAL

REFERENCE

TEST

ALPHABETIC-UPPER

ANY

COMMON

CONVERTING

END-CALL

END-DIVIDE

END-MULTIPLY

END-RECEIVE

END-SEARCH

END-SUBTRACT

EVALUATE

GLOBAL

ORDER

PADDING

REPLACE

THEN

New 1-0 status values have been added.

New communication status key values have been added.

Certain error conditions have been defined for

exponentiation (previously undefined)

When a COPY statement spans several lines, the whole

statement is processed, even if some continuation lines

are marked as debugging lines.

Order of evaluation of subscripts within PERFORM

statement is defined (previously undefined).

STOP eliminates from the queue any message partially

received by the run unit (previously undefined).

New communication error key values have been added.

COPY in a comment-entry is treated as a comment, not a true COPY statement (previously undefined)

After DISPLAY is executed, the output device advances to

the beginning of the next line (previously undefined).

The description of a data-item referenced in PROCEDURE

DIVISION USING . . . must not contain a REDEFINES phrase.
INCOMPATIBILITIES BETWEEN COBOL-74 AND COBOL-8X Page B-5

55. When the FOOTING phrase is not specified in LINAGE,

footing area exists (previously undefined) . no
APPENDIX C

SOURCES OF SAMPLE PROGRAMS AND AGENCIES INTERVIEWED

/

Sample programs were obtained from the following agencies:

1. Department of Agriculture (IBM)

2. Air Force Data Systems and Design Center (Burroughs and

Honeywell)

3. Army Materiel Support Systems Agency (IBM)

4. Bureau of the Census (UNIVAC)

5. Computer Systems Command (IBM)

6. Defense Logistics Agency (IBM)

7. Defense Mapping Agency (Burroughs and UNIVAC)

8. Housing and Urban Development (UNIVAC)

9. Bureau of Mines (Burroughs)

10.

National Bureau of Standards (UNIVAC)

11 . Naval Data Automation Command (IBM)
SOURCES OF SAMPLE PROGRAMS AND AGENCIES INTERVIEWED Page C-2

Interviews were held with the following:

1. George Baird, Director, Federal Software Testing Center

and John Caron, Director, Federal Conversion Support

Center (both within General Services Administration)

2. Gene Lynd and Kurt Molholm, ADPE Replacement Office,

Defense Logistics Agency

3. Steven Merritt, Accounting and Financial Management

Division, General Accounting Office

4. James Squier, Office of Information and Management

Services, National Oceanic and Atmospheric

Administration

5. Kenneth Cammie, Foreign Trade Division, Bureau of the

Census

6. Robert Ridgely, Office of Systems Integration, Social

Security Administration

7. Edward Crim and Roland Crenwelge, Information Storage

and Retrieval Division, Defense Mapping Agency

8. John Roach, Joan Sullivan, and Kurt Kroeger, Management

Systems Division, National Bureau of Standards

9. James Flaherty and Lisa Pershing,

Division, Internal Revenue Service

System Support
SOURCES OF SAMPLE PROGRAMS AND AGENCIES INTERVIEWED Page C-3

Questions for COBOL 8X Impact Study

The objective of this analysis is to determine the costs and

benefits to the Federal ADP community if the COBOL-8X prospective

FIPS is adopted. There are two fundamental dimensions we need to

understand in order to assess the potential impacts:

1. The current base case setting regarding the investment,

utilization, and associated costs of COBOL-related

activities in the Federal ADP community

2. The specific ways the prospective C0B0L-8X FIPS differs

from - and would cause changes to - the current

COBOL-related activities.

Questions of interest include:

1. How many COBOL programs are there in the Federal

inventory? What is the average COBOL program lifetime?

What is the annual rate of growth of the COBOL

inventory?

2. What is the distribution of COBOL programs by compiler

type (e.g., FIPS 21, FIPS 21-1, etc.)? What % of the

COBOL programs are in full compliance with COBOL

standards? Which standards?

3. What is the average turnover rate (replacement rate) for

COBOL compilers? How does it compare with the turnover

rate of hardware systems?

4. What is the distribution of the number of COBOL

compilers per ADP installation? What is the extra

effort involved to maintain an additional compiler?

5. How many of the items, proposed to be changed in COBOL

8X , are used currently? What is the frequency of use

per COBOL program? What is the distribution?

6. How will the proposed changes affect current programming

and maintenance practices? Are there reasonable

implications for productivity, reduction of errors,

documentation, processing performance, etc.?

7. How will the C0B0L-8X changes affect future conversions?

Will they increase the conversion effort? Will the

impact be different for different manufacturers'

systems?

8. What are the major problems with the development and

maintenance of applications programs - Programmer

turnover, high error rates, poor documentation, etc.?

Will the proposed COBOL 8X changes have a positive or

negative affect on these problems?
APPENDIX D

SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS

This appendix summarizes the system which was set up to

detect and count occurrences of the various incompatibilities.

Although the system is largely automated, human intervention was

either allowed or required at certain stages. In particular the

RESOLVER program makes it possible to view the actual portions of

source code which generated the recording of an incompatibility.
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-2

System Design for COBOL Incompatibility Sampling

Tapes ::rom various Federal agencies

V

1. Transfer

2. ad hoc -

3. SCAN01 -

4. DUPCHK -

5. UNDUP -

to disk

Assure margins aligned, delete trailing blanks to

save space

assure COPY entries are filled in (#147)

all four divisions present (#149)

check any non-blanks past cc. 72 (#155)

check for duplicate PROGRAM-ID (#150)

eliminate any duplicates found and compress

V

Disk files - one per source program,

numbered sequentially:

DMAB 0 001. COB CENSOOOl.COB ... DMABO 002 . COB CENS0002.COB ... etc

.

User suppl

mnemonic

,

last file

of series.

ies agency

first and

number

V

V V V

S CANO

1

SCANnn • • • SCAN99

preliminary handles handles a series

val idi ty

check

case #nn of easy cases

V v V

DMABO 1 . DAT DMABnn.DAT ... DMAB99.DAT

CENS01.DAT CENSnn.DAT ... CENS99.DAT

V

SCAN53 run

interactively to

parse DATE-WRITTEN

V

DMABO 1 . DAT (with computed dates)

CENS01.DAT

(continued)
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-3

* . DAT files (Record format:

agency, COBOL program number, line 1, line 2,

incompatibility code, certainty code (? or !)

or other supplementary information)

V

RESOLVER I - goes thru .DAT files according to interactive

commands and displays COBOL lines which

generated the various incompatibility records

V

DMAB01.DAT, DMAB02.DAT, . . .CENS01.DAT, CENS02.DAT, . .

.

(cleaned up versions)

V

STATSGEN | - generates various statistics, as requested

(by agency, incompatibility, ...)

V

STATS. PRT (reports)

Limitations:

Does not handle/distinguish qualified names - unpredictable

results for certain incompatibilities.

Does not analyze CORRESPONDING into elementary operations.

Assumes that a new data-descr iption entry begins on a new line.
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-4

Summary of treatment of incompatibilities, along with other

features detected for various reasons (see notes)

.

01 X 11 M 21 M

02 M 12 P ( 12) 22 M

03cP (03) 13 S 23 M

0 4cM 14 S 24 X

05 M 15 P ( 0 3) 25 M

06 M 16 M 26 S

07 M 17cM 27 S

08 M 18 M 28cM

09 S 19 M 29 M

10 M 20 M 30 P ( 30)

31 P ( 30) 41 X 51 M

32 X 42 P ( 4 2) 52 M

33 P ( 3 3) 43 P ( 4 2) 53 M

34 M 44 S 54 S

35 P ( 33) 45 M 55 P ( 12)

36 X 46 M 56 U

37 P ( 37) 47 M 57 N

38 P ( 37) 48 P(01) 58 N

39 S 49 P ( 30) 59 U

40cS 50 M 60 U

147-155 E

Key: c - incompatible in Sep. 81 document, but

since withdrawn

S - handled by a single program

M - handled by the catchall program, SCAN99

X - not detectible - ignored

P - handled together with another related case

(lower number used for program name)

E - these are not actual incompatibilities, but aspects

of a program indicating its readiness for processing,

plus some global information; all these are handled by

SCAN01, which documents their individual meaning

N - these are cases where new features of 8x might

profitably be used instead

U - code unused

Program # handles incompatibilities

1 48,147-155

3 3,15

9 9

12 12,55

13 13

14 14

26 26

27 27

30 30,31,49

33 33,35

37 37,38

39 39

40 40

42 42,43

44 44

54 54

57 57,58

99 2,4-8,10,11,16-23,25,28,29,34,45-47,50-53

not detected: 1,24,32,36,41
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-5

Documentation of Scanners for COBOL Impact Study

The following is a short description, for each of the

incompatibilities identified in the Draft Proposed Revised X3.23

American National Standard Programming Language COBOL, of the

rationale of the approach taken, and the algorithm implemented in

the syntactic analysis. It should be noted that the syntactic

analysis is not in all cases a foolproof method for finding all

incompatibilities. In some cases, incompatibilities cannot be

identified at all through syntactic analysis; conversely, in

other cases, the analysis can only find an upper bound (worst

case) for the number of incompatibilities. Nonetheless, it is

plausible to suppose that the analysis yields a roughly reliable

measure of the prevalence of features which would be affected by

the changes proposed in the draft.

Incompatibility: 1

Rationale: Since the character substitution is

implementor-defined, this is a case of implementor-defined syntax

(not merely semantics) and thus is undetectible.

Syntactic Analysis: None.

Incompatibility: 2

Rationale: The only place where the 74 standard allows an ALL

literal which is not associated with another item is in the

SPECIAL-NAMES paragraph.

Syntactic Analysis: There is a search for ALL within

SPECIAL-NAMES within ENVIRONMENT DIVISION.

Incompatibility: 3

Rationale: The contexts in which ALL may be associated with a numeric are in a MOVE or a comparison.

Syntactic Analysis: The DATA DIVISION is scanned and a list is

constructed of all numeric items, determined as an item

containing a PICTURE clause, whose picture-string does not

contain A or X. Only elementary names are entered in the list,

not the full qualified n:-e. Then, within the PROCEDURE

DIVISION, a scan is made for MOVE ALL and for IF, WHEN, or UNTIL

(which introduce a condition) . For MOVE ALL, all the receiving

items are checked against the list, and it's a hit when one is

found. For the conditions, they are

broken up, if necessary,

into the simple conditions connected by AND or OR. Each simple

condition is checked for a relation, with all the various
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-6

spellings (<, LESS , LESS THAN , etc.) and the comparands are

analyzed to see if one is an ALL literal and the other a numeric.

Abbreviated conditions are also handled and the "type" of the

default comparand (whether ALL or numeric or neither) is saved

and applied to later comparands. Thus: ''IF ALL "9" = ALPHA-ITEM

OR NUMERIC-ITEM' will be detected as a hit.

Incompatibility: 4

Rationale: The definition of some of the debug items has

changed, but not others. Any occurrence of a name whose

definition has changed is counted (including group items

containing a changed item)

.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for any

occurrence of DEBUG-ITEM, DEBUG-SUB-1, -2, or -3.

Incompatibility: 5

Rationale: Any occurrence is incompatible.

Syntactic Analysis: There is a search for MEMORY within the

OBJECT-COMPUTER paragraph within the ENVIRONMENT DIVISION.

Incompatibility: 6

Rationale: This is partially undetectible, since the option

'alphabet-name IS implementor-name' is a hard to isolate. But

any of the reserved words unique to the clause are detected.

Syntactic Analysis: There is a search for STANDARD-1, NATIVE,

THROUGH, THRU, or ALSO within the SPECIAL-NAMES paragraph within

the ENVIRONMENT DIVISION.

Incompatibility: 7

Rationale: Since this is a change in semantics, the best that

can be done is to look for cases where it can occur. The only

simple way to do this is to detect use of an indexed file,

together with the use of the PROGRAM COLLATING SEQUENCE clause.

In the absence of this clause, the default is native, and so the

new rule that native is used for indexed files would not result

in different program behavior. Clearly, this is a worst-case

analysis, since very few if any uses of indexed files rely on

behavior other than what 8x specifies.

Syntactic Analysis: The OBJECT-COMPUTER paragraph is scanned for
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-7

SEQUENCE. If found, a switch is set indicating its presence.

Then, there is a search for ORGANIZATION followed by optional IS,

followed by INDEXED within the FILE-CONTROL paragraph within the

ENVIRONMENT DIVISION. If both INDEXED and SEQUENCE are found, a hit is recorded.

Incompatibility: 8

Rationale: Any occurrence is incompatible.

Syntactic Analysis: Within SPECIAL-NAMES, within ENVIRONMENT

DIVISION, there is a search for CURRENCY, then an optional SIGN,

then IS, then SPACE, ZERO, QUOTE, HIGH-VALUE, or LOW-VALUE.

Incompatibility: 9

Rationale: Any occurrence is incompatible.

Syntactic Analysis: There is a search for ACCESS, optional MODE,

optional IS, any COBOL word, RELATIVE, optional KEY, optional IS,

and then the COBOL word which names the data-item, within

FILE-CONTROL paragraph. A table of all such data-names is

constructed. The DATA DIVISION is then scanned for these items

and their picture strings are examined for the occurrence of P.

For each one found with PICTURE P, a hit is recorded.

Incompatibility: 10

Rationale: It is impossible to determine the exact conditions

called for, so a search is made simply for the occurrence of the

MULTIPLE FILE TAPE clause. As is usual when the incompatibility

is semantic, this analysis yields a worst-case result, since most

such clauses will not actually cause the incompatible behavior.

Syntactic Analysis: There is a search for MULTIPLE FILE within

the I -O-CONTROL paragraph within the ENVIRONMENT DIVISION.

Incompatibility: 11

Rationale: Any occurrence is incompatible.

Syntactic Analysis: There is a search for RERUN within the

I -O-CONTROL paragraph within the ENVIRONMENT DIVISION.
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-8

Incompatibility: 12

Rationale: Any occurrence is incompatible.

Syntactic Analysis: The FILE SECTION of the DATA DIVISION is

scanned and each FD is checked for the presence of the LINAGE

clause. A table is constructed of all qualifying fd-names. The

PROCEDURE DIVISION is then scanned and each OPEN statement is

examined to see if any of the LINAGE fd-names are opened in

EXTEND mode. The scanner handles the opening of multiple modes

and multiple files in one statement. Thus if X is an fd-name

with LINAGE , it will be detected in: "OPEN INPUT A, B EXTEND C,

D , X, E, OUTPUT F."

Incompatibility: 13

Rationale: Although this is a semantic change, it can be

isolated syntactically. This is because the difference depends

not on the logical flow of the algorithm, but only on the

particular structure of the data-item and then its use as a receiving field.

Syntactic Analysis: First the DATA DIVISION is scanned and an

array keeps track of the current data structure. The path from

root (01 level data-name) to the current data-item is maintained.

Whenever a DEPENDING ON clause occurs, all containing items are

saved and associated with the DEPENDING ON variable, since their

lengths depend on it. Then the program is re-scanned and on this

second pass of the DATA DIVISION, once again the current path

within the data structure is maintained. A search is made for

the names of variables which were the object of the DEPENDING ON

clause (i.e., for those items upon which thse length of other

data-items depend) . When one is found, a check is made for all

the group items containing it, to see whether the length of any

of them depend on it (as determined by the table built during the

first pass) . If any such is found, then it is put into a second

table, which therefore contains exactly those items which both

depend on a given variable for their length and also contain that

variable. Finally, the PROCEDURE DIVISION is scanned and the

verbs ACCEPT, RECEIVE. . .INTO, RETURN. .. INTO, READ... INTO, MOVE,

and UNSTRING examined to see whether their receiving items are

among those in the second table.

Incompatibility: 14

Rationale: It"s not completely clear just which cases constitute

an incompatibility. The view taken is that whenever a PICTURE P

item is used and associated with a non-numeric item or appears in

a context where non-numeric operands are allowed, the behavior

may be different and so is incompatible.
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-9

Syntactic Analysis: First, the DATA DIVISION is scanned and two

lists are constructed: first a list of all PICTURE P data-items

(i.e., any item whose picture string contains at least one P) and

second a list of all elementary numeric items, except those in

the first list. Then, in the PROCEDURE DIVISION, there is a search for situations, either where a PICTURE P item is

associated with a non-numeric item, or where it is not associated

with any item, but appears in a context where it will be treated

as a non-numeric operand. The first case is covered by examining

all MOVES and conditions (introduced by IF, WHEN, or UNTIL) to

see if a PICTURE P item is moved to or from, or compared to, a non-numeric item. Multiple receiving fields in the MOVE are

handled, as are complex conditions and abbreviated conditions.

The second case is covered by looking for a PICTURE P item as an

operand of ACCEPT, DISPLAY, or INSPECT.

Incompatibility: 15

Rationale: Again, it is not clear just what constitutes an

incompatibility. We distinguished two cases: first any compound

condition, and second, the use of a compound condition in a program which bore traces of use of the DEBUGGING module. In the

first case, the only possible difference is that while a program

running under the "*74 rules might abort by evaluating

(unnecessarily) a given component of a condition, the same

program, under ^8X would keep running. The records generated to

denote these cases were flagged with a

' 7

'

. In the second case,

use of DEBUGGING with ALL REFERENCES might work somewhat

differently, since the evaluation of a later component of a condition might trigger a debugging report that would not appear

if the evaluation were omitted.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for all

conditions (introduced by IF, WHEN, or UNTIL), which are examined

for AND or OR. The resulting error file is generated with ' 7

' to

indicate a questionable incompatibility. A later routine scans

for the use of the word DEBUGGING anywhere within the

ENVIRONMENT, DATA, or PROCEDURE DIVISION (except in a comment

.line or nonnumeric literal), or for D in column 7. Either of

these is taken as evidence of debugging, and the records for

those programs are changed to indicate a possible

incompatibility.

Incompatibility: 16

Rationale: Any occurrence is incompatible.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

presence of ALPHABETIC.
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-10

Incompatibility: 17

Rationale: Any occurrence is incompatible.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

presence of ALTER.

Incompatibility: 18

Rationale: This is a semantic clarification, so all that can be

done is a worst-case search for all places where there might be a different effect. It is not obvious whether most compilers

already close files upon CANCEL or not.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

presence of CANCEL.

Incompatibility: 19

Rationale: Any occurrence is incompatible.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for REEL

or UNIT, followed by an optional WITH, followed by NO REWIND.

Incompatibility: 20

Rationale: Any occurrence is incompatible.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for

DISABLE, then OUTPUT or INPUT with optional TERMINAL, then a COBOL word, then an optional WITH, and then KEY.

Incompatibility: 21

Rationale: This is a semantic clarification. The scanner looks

for any case of a REMAINDER with a subscripted variable.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for

REMAINDER followed by a COBOL word, followed by '

Incompatibility: 22

Rationale: Any occurrence is incompatible.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-ll

ENABLE, then OUTPUT or INPUT with optional TERMINAL, then a COBOL

word, then an optional WITH, and then KEY.

Incompatibility: 23

Rationale: Any occurrence is incompatible.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

presence of ENTER.

Incompatibility: 24

Rationale: This situation cannot be detected syntactically.

Syntactic Analysis: None.

Incompatibility: 25

Rationale: This is a semantic clarification. The scanner finds

all instances of EXIT PROGRAM, which represents an upper bound on

the true incompatibilities (different behavior)

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

presence of EXIT PROGRAM.

Incompatibility: 26

Rationale: This is a semantic clarification for behavior that

occurs when subscripting is used in conjunction with INSPECT.

All such cases are detected.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for

INSPECT and then the entire statement is scanned for a

'

.

Incompatibility: 27

Rationale: Any occurrence is incompatible.

Syntactic Analysis: Within the I-O-CONTROL paragraph, two

entities are constructed. The first is an array of lists. Each

list in the array contains the fd-names appearing together in a SAME AREA or SAME SORT or SORT-MERGE AREA clause. Thus, there is

a list for each such clause. The second is a list of all

fd-names appearing in any SAME RECORD clause. Then the PROCEDURE

DIVISION is scanned for MERGE. A list of fd-names is taken from
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-12

the MERGE , consisting of its primary operand and all file names

between USING and GIVING or OUTPUT PROCEDURE. Each file from

this list is compared against the SAME RECORD list and any match

is counted as an incompatibility. Then the GIVING file, if any,

is added to the list of MERGE fd-names. This complete MERGE list

is now compared to each of the lists in the array (i.e. each of

the AREA lists) . If at least two MERGE files are found in any of

these AREA lists, it is counted as an incompatibility.

Incompatibility: 28

Rationale: Any use of OPEN 1-0 or EXTEND is a potential

difference in behavior and so all are flagged.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for any

occurrence of 1-0 or EXTEND.

Incompatibility: 29

Rationale: Any occurrence is incompatible.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

presence of REVERSED.

Incompatibility: 30

Rationale: This change defines the order of at most three move

statements: MOVE FI TO VI, MOVE F2 TO V2 , MOVE F3 TO V3 , where

Fn is the FROM variable and Vn is the VARYING (or AFTER)

variable. The only case where this would make a difference is

where one of the Fn's depended on one of the Vn"s (other than the

one it is being moved to) . For instance, MOVE A TO B, MOVE C TO

A is order-dependent because the sending field of one depends on

the receiving field of the other. Likewise for MOVE A (S) TO B,

MOVE C TO S. This dependence is sought by the scanner.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for

PERFORM statements with the VARYING option. All the control

variables (or literals) are captured. We use the convention that

Vn is the VARYING (or AFTER) variable, where n=l,2,3 (1 is the

"outer" or most inclusive variable, 3 the innermost) . Similarly,

the FROM operands are denoted by Fn. The primary name of the

Vn's (as opposed to subscripts) is isolated as DVn (for instance,

if V2 = 'A (2, X) ^

,

DV2 = 'A'). Each Fn is then checked to see

if any part of it (the primary or subscripts) depends on any of

the DVn's, other than the DVn with the same n. If any such

dependency is found, it is counted as an incompatibility.
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-13

Incompatibility: 31

Rationale: This change affects the order of two pairs of

operations: it switches MOVE F3 TO V3 and ADD B2 TO V2 and also

MOVE F2 TO V2 and ADD B1 TO VI, where Vn and Fn are as described

in number 30, and Bn is the BY variable. The only cases where

this makes a difference is, for the first pair, if F3 depends on

V2 or V2 or B2 on V3; for the second pair, if F2 depends on VI,

or B1 or VI on V2. These conditions are identified and counted

as incompatibilities when encountered.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for

PERFORM statements with the VARYING option. All the control

variables (or literals) are captured. We use the convention, as

above, that Vn is the VARYING (or AFTER) variable, where n=l,2,3

(1 is the "outer" or most inclusive variable, 3 the innermost)

.

Similarly, the FROM operands are denoted by Fn and the BY

operands by Bn. The primary name of the Vn^s (as opposed to

subscripts) is isolated as DVn (for instance, if V2 = 'A (2, X)',

DV2 = 'A'). Then, the following checks are done:

Does: depend on:

VI DV2

V2 DV3

B1 DV2

B2 DV3

F2 DV1

F3 DV2

If any such dependency is found, it is counted as an

incompatibility.

Incompatibility: 32

Rationale: This is a semantic clarification; since any program

containing a READ statement with the AT END clause could be

affected, it was not deemed worth searching for, since almost all

programs would contain such a statement. The only change,

however, would be for a program which would have aborted on AT

END; such a program would now keep running (somewhat like number

15) . Syntactic Analysis: None.

Incompatibility: 33

Rationale: Any occurrence is incompatible.

Syntactic Analysis: The FILE SECTION is scanned for all FD's and

SD^s. For each one, all the 01 entries are examined. A count is

kept of the number of 01's. Further, if any of them has a
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-14

PICTURE clause and the picture string is numeric (i.e., does not

contain either A or X) , then a switch is set. If, under an FD or

SD, there is more than one 01 and at least one has a numeric

PICTURE clause, then that fd-name or sd-name is added to a list

of such names. The PROCEDURE DIVISION is then scanned for all

occurrences of READ with the INTO option, and the fd-name of the

READ compared against the list. If it is found, an

incompatibility is recorded.

Incompatibility: 34

Rationale: This is a semantic change? it is very difficult to

analyze a program syntactically in a detailed way to see where it

would make a difference. Therefore, the scanner simply finds

instances of the RECEIVE statement.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

presence of RECEIVE.

Incompatibility: 35

Rationale: Any occurrence is incompatible.

Syntactic Analysis: The analysis is the same as for number 33,

except that the PROCEDURE DIVISION is scanned for RETURN, rather

than READ.

Incompatibility: 36

Rationale: This is a semantic clarification; since any program

containing a STOP RUN statement could be affected, it was not

deemed worth searching for, since almost all programs would

contain such a statement. It is not clear what detectible effect

the new specification might have; presumably the state of the

unclosed files might be different.

Syntactic Analysis: None.

Incompatibility: 37

Rationale: This is a semantic clarification of the order in

which subscripts are evaluated within a STRING statement. It is

difficult to analyze the possible different effects beyond simply

noting whether subscripts are present.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

STRING statement. The remaining text of the statement is scanned
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-15

for the presence of a '

.

Incompatibility: 38

Rationale: This could affect only those UNSTRING statements for

which the operand of the DELIMITED BY clause is subscripted. As

usual with semantic clarifications, this represents a worst-case

analysis of the incompatibility.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

UNSTRING statement. Each the operands of the DELIMITED BY clause

(separated by OR) is isolated in turn, and examined for the

presence of a ' (taken to indicate subscripting).

Incompatibility: 39

Rationale: Any occurrence is incompatible.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

WRITE statement. Within the text of the statement, a search is

done both for PAGE and for either EOP or END-OF-PAGE. If both

are found it is counted as an incompatibility.

Incompatibility: 40

Rationale: The only case in which the deletion of independent

segments could possibly affect the logical behavior of a standard

'74 program is when an independent segment executes an ALTER.

This change is really semantic, because syntactically, segment

numbers greater than 49 are still legal; they are. simply not

treated as independent. As usual for semantic changes, this is a worst-case analysis, since not all such ALTERS will actually

cause different behavior.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for

sections with segment numbers of 50 or greater. Within such

segments, all ALTERS are flagged as incompatibilities.

Incompatibility: 41

Rationale: This incompatibility has no effect on programs beyond

that specified in numbers 42 and 43.

Syntactic Analysis: None.
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-16

Incompatibility: 42

Rationale: The only case for which this can have an effect is

when a program contains an OPEN I-O, a READ NEXT, and a WRITE

statement for the same file. Such a combination does not, of

course, guarantee different behavior, which depends on the

program's logic flow. All the analysis attempts to do, however,

is note the presence of these three statements.

Syntactic Analysis: First, the FILE SECTION is ' scanned and a table is built. Each entry in the table consists of one fd-name

and all associated 01-names. Then, within the PROCEDURE

DIVISION, there is a search for OPEN statements, READ statements

and WRITE statements. There is also a two-dimensional table

maintained, for which the first dimension indicates which file is

being checked, and the second dimension, which kind of statement

(OPEN, READ, or WRITE). When an OPEN is found, all the files (if

any) being opened as 1-0 are noted by an entry being made in the

appropriate slot of the table. When a READ is found, with the

NEXT option, an entry for that file is made in the table. When a WRITE is found, the record-name is compared against the table

built during the scan of the FILE SECTION, to link it back with

the fd-name. Then an entry in the two-dimensional table is made

for that file. Whenever any entry is made in the table, a check

is done to see if the other two entries for that fd-name have

been filled. If so, this signifies the presence of all three

statements for that fd-name, and an incompatibility is recorded.

Incompatibility: 43

Rationale: The rationale is exactly the same as for number 42,

substituting REWRITE for WRITE.

Syntactic Analysis: Same as for number 42, substituting REWRITE

for WRITE.

Incompatibility: 44

Rationale: The presence of one of the new reserved words (other

than within a comment-line, a comment-entry as in the

IDENTIFICATION DIVISION, or a nonnumeric literal) as a user-defined identifier is an incompatibility. If such a word is

used as a keyword of an implementor-defined extension, it is not

counted, since such use is neither guaranteed nor forbidden by

either the '74 or '8x standard.

Syntactic Analysis: The IDENTIFICATION DIVISION is skipped,

because reserved words in the comment-entries are insignificant.

The other divisions are scanned for any occurrence of any of the

new reserved words (except, of course, within comment-lines, or

nonnumeric literals) . Each occurrence is counted as an
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-17

incompatibility. The scanner also records which word was found.

Implementor extensions are deleted ad hoc.

Incompatibility: 45

Rationale: Any use of FILE STATUS is potentially incompatible,

although the precise analysis depends on the use of old

implementor-defined codes and their relation to the new codes.

Syntactic Analysis: The FILE-CONTROL paragraph within the

ENVIRONMENT DIVISION is scanned for any occurrence of STATUS.

Incompatibility: 46

Rationale: Any use of the communication status codes is

potentially incompatible, although the precise analysis depends

on the use of old implementor-defined codes and their relation to

the new codes. All CD's have an associated status key.

Syntactic Analysis: The COMMUNICATION SECTION of the DATA

DIVISION is scanned for the occurrence of any CD.

Incompatibility: 47

Rationale: Any occurrence is potentially incompatible; however,

a real incompatibility exists only if the operands are not

checked as being mathematically valid.

Syntactic Analysis: Within the PROCEDURE DIVISION, any

occurrence of " ** " is counted as an incompatibility.

Incompatibility: 48

Rationale: Any such COPY statement is potentially incompatible.

Syntactic Analysis: Whenever a COPY statement is found, a switch

is set if the end of the statement does not appear by the end of

that line. Subsequent lines are examined until either an end of

statement (signified by a "

. " followed by a space) or a debug

indicator ("D" in column 7) is found. If the debug indicator is

found, an incompatibility is recorded. If an end of statement is

found, the switch is re-set to indicate the end of the COPY

statement.
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-18

Incompatibility: 49

Rationale: Any subscript appearing within a PERFORM. . .VARYING

statement is potentially incompatible, since its setting could

occur any time during the processing of the PERFORM.

Syntactic Analysis: Within the text of all PERFORM. . .VARYING

statements, a search is done for any user-defined word (i.e. not

a reserved word), followed by a "(", to indicate subscripting.

Any such occurrence is recorded as an incompatibility.

Incompatibility: 50

Rationale: Since virtually all programs contain STOP, this

applies to any program doing a RECEIVE. Therefore, the scanner

merely finds instances of the RECEIVE statement.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

presence of RECEIVE.

Incompatibility: 51

Rationale: This could potentially affect any program using an

output CD, since the error key is associated with such entities.

Syntactic Analysis: Within the COMMUNICATION SECTION, the

scanner looks for CD (in the A margin), followed by a COBOL word,

optionally followed by FOR, followed by OUTPUT.

Incompatibility: 52

Rationale: The only comment-entries are in the IDENTIFICATION

DIVISION. Any occurrence of the reserved word COPY therein is a potential incompatibility. It would actually be incompatible

only if used as a COPY statement and not a comment.

Syntactic Analysis: The scanner looks for COPY anywhere before

the ENVIRONMENT DIVISION.

Incompatibility: 53

Rationale: Any DISPLAY is potentially incompatible. If,

however, the vendor performs the required positioning (which most

do)

,

then it would not be a real incompatibility.

Syntactic Analysis: The PROCEDURE DIVISION is scanned for the

presence of DISPLAY.
SYSTEM DESIGN FOR THE ANALYSIS OF SAMPLE COBOL PROGRAMS Page D-19

Incompatibility: 54

Rationale: Any such occurrence is incompatible.

Syntactic Analysis: Within the LINKAGE SECTION, a search is done

for 01, 77 or 1, followed by a COBOL word, followed by REDEFINES.

Such COBOL words are saved in a table. Then the PROCEDURE

DIVISION header is examined for the USING phrase, followed by any

COBOL words. If any of these COBOL words in the USING phrase

match any of those in the table, a hit is recorded.

Incompatibility: 55

Rationale: Any such occurrence is potentially incompatible.

Syntactic Analysis: The FILE SECTION is scanned for the presence

of LINAGE. When found, the remainder of the clause is searched

for the presence of FOOTING. If FOOTING is not found, a hit is

recorded.

*U.S. GOVERNMENT PRINTING OFFICE s 1983 0-380-997/857

U.S. DEPT. OF COMM. 1. PUBLICATION OR 2. Performing Organ. Report No. 3. Publication Date BIBLIOGRAPHIC DATA

REPORT NO.

SHEET (See instructions) NBSIR 83-2639 March 1983

4. TITLE AND SUBTITLE

Cost-Benefit Impact Study on the Adoption of the Draft Proposed Revised

X3.23 American National Standard Programming Language COBOL

5. AUTHOR(S)

Marco Fiorello & John Cugini

6. PERFORMING ORGANIZATION (If joint or other than NBS, see instructions) 7. Contract/Grant No. NATIONAL BUREAU OF STANDARDS and Aurora Associates, Inc.

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

S. Type of Report & Period Covered

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State. ZIP)

NBS

10. SUPPLEMENTARY NOTES

~| Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11. ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant

bibliography or literature survey, mention it here)

The purpose of the study is to assess the estimated costs and benefits

for the Federal Government which would result from adoption of the

proposed revision of American National Standard COBOL as a Federal

Information Processing Standard (FIPS). Potential benefits of $90.2-

million have been identified, stemming primarily from improved

productivity in both the development and maintenance of COBOL programs.

Estimated costs of $17. 9-million have been identified, arising .principally from the effort needed to convert old COBOL programs to the new

specification, which is incompatible in some respects with the current

specification. In support of the study, we conducted interviews with

Federal ADP managers and officials, and also analyzed over one thousand

Federal COBOL programs for various syntactic characteristics. The study

concludes that the potential benefits of a new standard outweigh the

estimated costs.

12. KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolons)

COBOL; compatibility of programming language standards; conversion costs

for COBOL programs; cost-benefit analysis of COBOL standards; Federal use

of COBOL; FIPS for COBOL; standardization of COBOL.

13. AVAILABILITY

|~x| Unlimited

| | For Official Distribution. Do Not Release to NTIS

~| Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.

20402.

[~x] Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

15. Price
*