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

[Steve Litt <slitt@troubleshooters.com>]

On Fri, 6 Oct 2017 21:47:38 -0400
Walt Mankowski <waltman@pobox.com> wrote:

> On Fri, Oct 06, 2017 at 02:01:35PM -0400, Steve Litt wrote:
> > 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.   
> 
> I'm not saying this is great, but most Cobol programmers are doing
> maintenance on programs that were written 30 years ago when this
> seemed perfectly natural to them, and the systems were built with this
> in mind.

How true. When I hit the professional programming scene in 1984, with
my brand new tool, Functional Decomposition, my productivity was
red-hot, and I was sought everywhere. 20 years later, when I understood
what I'd been doing for the last 20 years, and understood the
importance of deciding your data model first and foremost, I can
understand why one "written in stone" set of data structures might
indeed have been a very good thing. And let's face it, one could always
manually create his own namespace (perhaps all vars preceded by "loc-")
that would be handled by procedures as if it had random junk when first
used, and it would be erased upon exit. I met those Cobol guys. While
guys like me thought ahead by doing functional decomposition in an
outline or diagram, those guys might have thought ahead by deciding
data.

> 
> > 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.  
> 
> This seems like it would only be an issue if you were using Cobol in a
> multithreaded environment. I see some references to this online in
> IBM's documentation, but I'm guessing this is pretty rare.

It's a problem well outside of multithreading, I think. Say executable
A uses subprogram 1, and so does executable B. If executables A and B
are running at the same time, each accessing subprogram 1 over and
over, I would think that local vars' static nature would mean A and B
would clobber each others data within subprogram 1.


> 
> > 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've never used OO Cobol, so I can't comment on that.
> 
> > 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.  
> 
> I guess that would be nice, but I can't see how that would possibly
> work. PERFORM is basically like a GOSUB in Basic. All it does is jump
> to another section of the code, execute it, and jump back. There's
> nearly 60 years of legacy code that expects it to work that way.

I think that if the compiler allowed, but did not demand, a local data
division within a paragraph, that wouldn't bust old programs. Of
course, like you say, when you have 60 years of legacy code that runs
the biggest financial and insurance organizations, the less you tamper
with the language, the better.
 
SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___________________________________________________________________________
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