COBOL Variable Scope

Variable scope in COBOL determines where a name (a data item, paragraph, or other name) is visible. In a single program, names you declare are local to that program. When you use nested programs (one program CONTAINed inside another), the contained program can see names from the containing program only if they are declared GLOBAL. This page explains local and global scope, the GLOBAL clause, and how name resolution works in nested programs.

Explain Like I'm Five: Scope

Scope is like "who can see this name." If you write a variable in your program and do not say GLOBAL, only that program can use it. If you put a small program inside your program (nested program), the small program cannot see your variables unless you labeled them GLOBAL. So GLOBAL means "my inner programs can see this too." The inner program cannot show its own variables to the outer program; they stay inside the inner program.

Local Names

By default, names in COBOL are local. A data item or paragraph declared in a program is visible only in that program. It is not visible in programs that contain it (callers) or in programs that it contains (nested programs), unless you use the GLOBAL clause. So each program has its own "space" of names, and local names do not leak in or out.

Global Names

When you add the GLOBAL clause to a data item or paragraph, that name becomes visible in the program that declares it and in every program that is directly or indirectly contained within it. So the containing program declares a item with GLOBAL, and any nested program can reference that name without declaring it. Subordinate items under a global group item are also considered global. This allows shared data between the outer and inner programs without passing parameters.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
       IDENTIFICATION DIVISION.
       PROGRAM-ID. OUTER.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  WS-SHARED        PIC 9(5) GLOBAL.   *> Nested program can use this
       01  WS-LOCAL         PIC X(10).          *> Only OUTER can use this
       PROCEDURE DIVISION.
           MOVE 0 TO WS-SHARED
           CALL 'INNER'
           DISPLAY WS-SHARED
           STOP RUN.
       
       IDENTIFICATION DIVISION.
       PROGRAM-ID. INNER.
       PROCEDURE DIVISION.
           ADD 1 TO WS-SHARED   *> Allowed: WS-SHARED is GLOBAL in OUTER
           *> MOVE 'X' TO WS-LOCAL   *> Not allowed: WS-LOCAL is not visible
           EXIT PROGRAM.
       END PROGRAM INNER.
       END PROGRAM OUTER.

Nested Programs and Visibility

A nested program is declared with CONTAINED or physically placed inside another program (END PROGRAM inner, END PROGRAM outer). The contained program can reference only: (1) names it declares locally, and (2) names that are GLOBAL in a containing program. The containing program can reference only its own names and GLOBAL names it declares; it cannot reference names that exist only in a contained program.

Name Resolution Order

When the compiler (or runtime) resolves a name in a contained program, it searches in this order: (1) the current program (local names and names declared there), (2) if not found, GLOBAL names in the immediately containing program, (3) if not found, GLOBAL names in the next outer container, and so on. The first match is used. So if the nested program declares a name that is also GLOBAL in an outer program, the local declaration wins (shadowing).

Step-by-Step: Sharing Data with a Nested Program

• In the containing program, declare the data item you want to share in WORKING-STORAGE (or appropriate section) and add the word GLOBAL.
• Code the nested program (CONTAINED or before END PROGRAM outer).
• In the nested program, reference the name without declaring it again. It refers to the global item in the outer program.
• If the nested program needs to hide the global (use a local name instead), declare a local item with the same name; that local name will shadow the global in that program only.

Best Practices

• Use GLOBAL only for data that must be shared with contained programs; keep other data local to avoid accidental use or confusion.
• Avoid shadowing (same name local and global) unless intentional; it can make code hard to follow.
• Document which names are GLOBAL and shared with which nested programs.

Related Concepts