Binding a program in Cobol ILE 1

[JSutor]

When binding a program in Cobol ILE is the data declared in the main "module" global variables while those declared with in a sub-program/"module" local variables similar to the concepts in Java and C++??

 

[fredericofonseca]

Can you give an example of what you are trying to do? with some code?



Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[JSutor]

I am not working on any particular code just trying to get a better understanding of how it works. Any help would be nice!

 

[wahlers]

About global and local in COBOL for the C++ and JAVA programmer.

Note:
I only know the details up till and including COBOL-85. There now is a new COBOL standard, informally known as, COBOL-2002. COBOL-2002 is a hybrid language, like C++, it is fully object oriented but still supports the old, non object oriented, standard (minus a few obsoleted statements).

Instead of 'global' or 'local' it might be better to use the more general term 'scope'.

The scope of a variable in a program having no contained (a.k.a. nested) programs always is global.

(code) example:

IDENTIFICATION DIVISION.
PROGRAM-ID. aProgram.
DATA DIVISION.
WORKING-STORAGE SECTION.
   ...
  05  someVariable  PIC  .(..).
   ...
PROCEDURE DIVISION.
   ...
 statements
   ...
END PROGRAM  aProgram.

The variable 'someVariable' is known, and can be addressed, everywhere within the procedure division.

The scope of a variable in a program having one or more contained (a.k.a. nested) programs is defined by its location and the usage of the global keyword (example following).

(code) example:

IDENTIFICATION DIVISION.
PROGRAM-ID. mainProgram.
DATA DIVISION.
WORKING-STORAGE SECTION.
   ...
01  declaredGlobal   GLOBAL.
  05  variable1  PIC  .(..).

01  NOTdeclaredGlobal.
  05  variable2  PIC  .(..).

   ...
PROCEDURE DIVISION.
   ...
 statements
   ...

IDENTIFICATION DIVISION.
PROGRAM-ID. firstContainedProgram.
PROCEDURE DIVISION.
   ...
 statements
   ...
END PROGRAM  firstContainedProgram.

IDENTIFICATION DIVISION.
PROGRAM-ID. secondContainedProgram.
DATA DIVISION.
WORKING-STORAGE SECTION.
01  variable3  PIC  .(..).

PROCEDURE DIVISION.
   ...
 statements
   ...
END PROGRAM  secondContainedProgram.

END PROGRAM  mainProgram.

Now the main program contains 2 nested programs:
(firstContainedProgram and secondContainedProgram)

The scope (visibility) of variable2 is the main program only. Variable1 can not be used in either firstContainedProgram or secondContainedProgram.

variable1 is declared 'GLOBAL' and the scope is therefore global. It can be used in the main program, or the first- or second-containedProgram.

variable3 is defined in the secondContainedProgram. Variable3 can only be used within the secondContainedProgram. It is therefore 'local' to the secondContainedProgram.

Contained (=nested) programs can only be called within the same source in which it is defined.
Contained programs can be nested indefinitely (that is: can themselves have contained programs).

Contained (=nested) programs have a hierarchy. This hierarchy is defined by the way these programs are nested and by the use of the 'COMMON' identifier. This 'COMMON' identifier plays a role in defining the visibility of the CALL structure.

For details of the above see the COBOL reference manual.

Answer to the JAVA (or C++) programmer:

Yes...local and global variables do exists, as explained above, but there is no direct 1 to 1 translation to JAVA.


Regards, Wim Ahlers.

 

[wahlers]

...additional!

Note: The 'local' and 'global' discussion before relates to the internal workings of one load module (=one source) only!

This load module itself might be a main or sub program (which is irrelevant).
All variables within a loadmodule are private unless passed by reference. In that case the contents of the variable is 'shared' between the caller and called program. And can be modified by both of them.

The called program in turn may pass the variable (actually the address of the variable) to another (sub)program (and so on, and so on...). Each (sub)program receiving the (address of) the variable can also modify the contents of this variable.

The default usage in a COBOL call statement is by reference.

(see the COBOL reference manual for the exact details).

 

[wahlers]

I still have to clarify a detail...

I mentioned passing variables by reference.
You can als pass variables by content.

Following is a code example:

IDENTIFICATION DIVISION.
PROGRAM-ID. aProgram.
DATA DIVISION.
WORKING-STORAGE SECTION.
   ...
  05  variableX   PIC  .(..).
  05  varaibleY   PIC  .(..).
   ...
PROCEDURE DIVISION.
   ...
  CALL  aSUBprogram  USING
  , by reference  variableX
  , by content    variableY
  END-CALL
   ...

aSUBprogram is the called (sub)program.
variableX is passed by reference. This actually means that the address location of variableX is passed to the (sub)program.
This means that this (sub)program (or maybe one or more of its subordinate (sub)programs) can modify the contents.

Whereas variableY is passed by content. Passing by content means that a copy is taken from variableY and the address of this copy location is passed to the (sub)program.
The (sub)program (or one of its subordinates) may still modify this variable, but they only modify the storage contents of the copy and NOT(!) the storage contents of the original variableY.

I hope I am now, more or less, complete...!


Regards, Wim Ahlers.

p.s. errata!

The sentence:
The scope (visibility) of variable2 is the main program only. Variable1 can not be used in either firstContainedProgram or secondContainedProgram.

Should have been:
The scope (visibility) of variable2 is the main program only. Variable2 can not be used in either firstContainedProgram or secondContainedProgram.

 

[JSutor]

wahlers,
excellent description of the whole subject, I have much better understanding of the subject now! and for a great job i'll give ya a start!!

Thanks
John Sutor

 

[wahlers]

...as usual, the devil is in the details.

I did not specify all the details.
E.g.:

I did not show the difference between static and dynamic calls.

I did not explain record structures, neither did I explain specific addressing issues (and what can go wrong with it - addressibility errors - ).

I did not show the posibilities of reference modification and the posibility of adress pointers (a non-standard feature by the way!).

I did not want to confuse you with such details.
Consider the previous information as a broad overview.

Regards, Wim.