Walt Mankowski on 6 Oct 2017 18:47:45 -0700

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

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

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.

> 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.

> 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.


Attachment: signature.asc
Description: PGP signature

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