Re: CoBOL moved to OO

From: Pierra (pierra_at_sprynet.com)
Date: 01/08/04 

Date: Thu, 08 Jan 2004 17:27:13 GMT

As a follow-up to Howard's comment,

On the online/interactive mainframe systems I've worked on, They've all
been too large to be contained in 1 program. What a headache that
would be. (These systems were CICS and ADS/Online (similar to
CICS/COBOL, the difference being one is program centric (CICS/COBOL) and
the other is map centric (ADS/Online). Any COBOL programmer could
follow an ADS/Online program easily.)

In any case, the basic operating of these systems is
1. Grab a chunk of storage dedicated to an individual user (the storage
is bound checked such that if anything is "written" over the end of the
storage the transaction would terminate.)
2. Display the menu map.
3. Based on the response of the menu, relinquish control (pick your
verb) to another program to accomplish the desired function.
4. Program to accomplish desired function executes and calls or
transfers to any number of programs (sub-programs) to accomplish it's
functions.
5. At function termination, give control to the menuing program and
start over.
6. All screen interaction is pseudo-conversationsl . (Note for the
un-initiated: pseudo-conversational means that control is returned to
the operating system upon screen display. A new program is initiated
upon completion of activity on the screen.)

All "common" data is put into the "chunk" of storage obtained initially.
  (Obviously, intermediate "chunks" of storage may be obtained as needed
throughout the process.)

"Conversational" programs (which apparently is what OOP is all about
based on Donald Tees explanations( are IMHO) more appropriate for those
systems where all processing is done locally (ie on an individual's
machine.) A "conversational" program on a mainframe would cause all
users of the system involved to wait until an individual actually
interacted with the program - a performance nightmare!

Functionally, to me, mainframe online processing as I describe it above,
  seems to me to be what OOP is all about. Granted, code within the
modules are procedural (as is code within the individual OOP modules as
far as I can tell.)

Donald, (or any other OOP guru) what am I missing? I mean, display map
(paint screen), get database info, modify database info, handle menuing
tasks etc all seem to be "objects" to me. It's been a looooooooooooong
time (early 70's) since I actually had to write terminal code (put this
character at terminal byte "A", but this character at byte "DC" etc.) to
display information on a screen. And I never had to write code to
actually read or write data to a database.

*** - who wrote his first program in 1967.

Howard Brazee wrote:
> On 7-Jan-2004, Donald Tees <donald_tees@nospam.sympatico.ca> wrote:
>
>
>>Consider the traditional Cobol system based on a main menu, with each
>>program being a subroutine, and the common setup data being read by the
>>menu. Structurally, it normally looks as follows.
>>
>> Main program
>> call read setup stuff
>> menu loop
>> choose program
>> call program using setup-data
>> end menu loop
>> stop.
>
>
> On mainframes that I have worked on, the menu programs have been outside of
> CoBOL programs. But it seems that menus are pretty much thinking in OO anyway.
>
> Do you have any non-interactive examples where OO commands are useful to people
> who don't "think" in OO?
>
> Or maybe I misunderstand - that you are recommending it to replace all called
> programs. From reading your post, I think this may be the case - that you
> think passed arguments are a pain, and that programmers should learn to use
> "invoke" as a way of avoiding passing arguments.