Re: [open-cobol-list] Information hiding

[Brian Tiffin]

On Thu, 28 Feb 2013 01:10:34 -0500, Patrick  
<address@hidden> wrote:

> Hi Everyone
>
> I am studying Cobol everyday and making progress. I do have a question
> about information hiding though.

Yeah, about that...  ;-)

> In most languages I have encountered there is some sort of associative
> array. If we have arrays foo and boo they could both have a key doo. doo
> is local to the array. In Cobol it looks like everything in the working
> storage section is global.  I realize that with foo.doo and boo.doo
> there are not really two doo variables as they are part of a larger
> structure but for simplicity sake, we could sort of think of them as two
> variables. Is it possible to create this in Cobol?

Yes and no.  Yes, in that you can set up SEARCH tables, no in that it's  
likely not as implicit as languages you may be used to.

See  
http://opencobol.add1tocobol.com/#does-opencobol-support-table-search-and-sort  
for examples of linear SEARCH and binary SEARCH ALL.

On fully qualified names.

You can have

01 main-record
   05 inner-group
      10 data-item-1
      10 data-item-2

01 other-record
   05 inner-group
      10 data-item-1
      10 data-item-2
      10 data-item-3

Assess to data-item-1 and data-item-2 would require a qualified name as in

MOVE data-item-1 IN other-record TO data-item-1 IN main-record

You can have as many IN clauses in a fully qualified name as it takes.   
Note that COBOL is pretty smart about resolving the data name space, and  
the above didn't need to be the complete

MOVE data-item-1 IN inner-group IN other-record TO data-item-1 IN  
inner-group IN main-record

Historically, COBOL has provided some level of name hiding using CALL and  
subprograms.  The WORKING-STORAGE name space can be managed with nested  
and non nested subprograms.  OpenCOBOL also has support for LOCAL-STORAGE  
but it's not quite the same thing as associative arrays.

Once we get OC2.0 out and about, we get FUNCTION-ID support and then a  
chance at real functional encapsulation, where a function can return COBOL  
field structures but not need to name them.

MOVE FUNCTION make-me-a-sandwich TO my-hero

The data names used in FUNCTION-ID. make-me-a-sandwich. will be hidden  
from mainline COBOL programs, and yet can be wielded with simple MOVE type  
operations. I'm really looking forward to when that can be released.

> I could imagine needing to use the same name twice. I thought that the
> 05 tagged variables were local to their 01 parent but it now seems that
> they are sort of tethered together with it but also global.

Umm, no, sub leveled names don't need to be unique, and the compiler will  
need qualified names for access to duplicate named fields below level 01.   
Subgroups are 'tethered' to records though, as part of their hierarchy.   
COBOL can even do a little magic with MOVE CORRESPONDING some-record TO  
other-record, which will move only same-named subfields between  
some-record and other-record.

> Thanks for reading, hope this email was clear, I am pretty sleepy-Patrick

Patrick.  I doubt I actually answered your question.  It's a big topic,  
and please ask more if you need more details.

Cheers,
Brian