Steve Litt on 6 Oct 2017 11:01:41 -0700


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Cobol: was Topic for North this month


On Thu, 5 Oct 2017 20:24:52 -0400
Walt Mankowski <waltman@pobox.com> wrote:

> On Thu, Oct 05, 2017 at 08:07:38PM -0400, Steve Litt wrote:
> > On Thu, 5 Oct 2017 12:12:19 -0400
> > Walt Mankowski <waltman@pobox.com> wrote:
> >   
> > > We still need a speaker for North on Tuesday.  I haven't done my
> > > COBOL and punch cards talk there yet. Any interest?  
> > 
> > I always liked Cobol, except for the fact that every variable was a
> > global variable, which drove me away.
> > 
> > Did Cobol ever get local variables inside procedures or whatever
> > their subroutines are called?  
> 
> Yes, but it's a little tricky because Cobol uses different terminology
> than modern languages. Cobol's equivalent of functions or subroutines
> are called "subprograms". Variables declared in the local-storage
> section of the data division are dynamically allocated and initialized
> each time the subprogram is run, much like local variables in
> functions are.

Yes, I remember now. Subprograms must be their own separate file and
must be linked into the executable. The trouble with this is that this
requirement of an independent file has a chilling effect on one's use
of local variables. If you've been doing Python or C or C++ or Java,
you've come to think of local variables as being free, you use them
consistently, and you've come to think of your subroutines as
impeneratable except using arguments. If Python declared that all
variables are global except those declared in a new construct starting
with "defext" instead of "def", and all "defext" must be defined in
separate files, there would be war in the streets. 

Then there's the fact that local variables in subprograms are static
(http://www.cs.scranton.edu/~mccloske/courses/cmps340/lecture_notes/cobol_subprogs.html),
meaning that if different instances of the subprogram are running at
the same time, even if called by completely different programs, they
will interfere with each others' data.

Probably everything I wrote in the preceding two paragraphs is rendered
moot by OO Cobol, which I understand became available in 2002 and
therefore should be fairly mature by now. That's nice, but it's even
nicer when you can get local variables without going all-out OO.

I'd have liked it better if regular ordinary paragraphs callable with
the PERFORM command could have their own DATA DIVISION or whatever it
should be called.

SteveT

Steve Litt
September 2017 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug