Re: COBOL and the Java scripting framework ? (Re: Are there samples of COBOL methods or classes?

[Rony G. Flatscher]

On 30.06.2023 09:44, Rony G. Flatscher wrote:

On 28.06.2023 17:26, Tom Ross wrote:

Please check out the examples in the COBOL Programming Guide, in
Part 6. Developing object-oriented programs

GO here:https://www.ibm.com/support/pages/node/611415
Select which release you are interested in and then
click "Product Documentation"


thank you, Tom. Could get to  and from there to 
the programming guide at .


It seems that OO COBOL allows interacting with Java via JNI (Java native interface) only. 6.4 adds 
the ability to invoke static Java methods without OO COBOL.


Not having any of the necessary infrastructure (mainframe ;) , OO COBOL and Java) there is nothing 
I could do. So maybe just hinting of what would become possible if anyone with the OO COBOL-Java 
skills would come with showing how to code the following Java program in OO COBOL.


Such an example would serve as a nutshell example that would demonstrate how to invoke scripts 
from OO COBOL in any scripting language for which an implementation of javax.script.Engine exists 
including supplying arguments (stored in a Java array of type java.lang.Object) and fetching the 
result.


To make this as flexible (and thereby as usable) as possible, the following Java program will take 
the name of a file containing a script as a single argument, and then will load with the help of 
the Java scripting framework the appropriate scripting engine to execute the script, and supply as 
an argument the name of a Java system property which the script should return to the caller.


Here the Java code that should be transcribed to COBOL:

   import javax.script.*;
   import java.io.File;
   import java.io.FileReader;

   class Test
   {
    public static void main (String args[])
    {
    if (args.length==0)
    {
    System.err.println("file name missing...");
    System.exit(-1);
    }
    String fileName = args[0];    // get filename
    String extension    = 
fileName.substring(fileName.lastIndexOf(".")+1);
    ScriptEngineManager sem = new ScriptEngineManager();
    ScriptEngine    se  = sem.getEngineByExtension(extension);

    Object result = null;
    try
    {
    ScriptContext sc    = se.getContext();
    // add filename
    sc.setAttribute(se.FILENAME, fileName  , sc.ENGINE_SCOPE);
    // add some arbitrary arguments
    Object scriptArgs[] = new Object [] { "first", "", "trois", null, 
"cinque" };
    sc.setAttribute(se.ARGV    , scriptArgs, sc.ENGINE_SCOPE);
    // create a FileReader from File
    FileReader f    = new FileReader(new File(fileName));
    result=se.eval(f);  // read and execute script
    }
    catch (Throwable t)
    {
    System.err.println("Oops, some exception occurred: "+t);
    }
    System.out.println("script's result: "+result);
    System.exit(0);
    }
   }

Here a Rexx file (can be any Rexx script):

   parse source s
   say "source :" s
   parse version v
   say "version:" v
   say "there are" arg() "arguments supplied:"
   do i=1 to arg()
   say "   #" i":" arg(i)
   end
   return 43

The Java program "Test", once compiled can then be used to run any script (not only Rexx) from a 
script file where the file extension determines which scripting language should get loaded to run 
the script in the file. Here an example of running the Java program supplying the name of a file 
containing a Rexx script:


   G:\tmp\bsf4oorexx\cobol>java Test rexxscript.rex
   REXXout>source : WindowsNT SUBROUTINE rexxscript_ori.rex
   REXXout>version: REXX-ooRexx_5.1.0(MT)_64-bit 6.05 6 Jun 2023
   REXXout>there are 6 arguments supplied:
   REXXout>   # 1: first
   REXXout>   # 2:
   REXXout>   # 3: trois
   REXXout>   # 4: The NIL object
   REXXout>   # 5: cinque
   REXXout>   # 6: a Slot.Argument
   script's result: 43

---

The script code can also be supplied directly as a String to the script engine's eval() method 
"res=eval(String scriptCode)", such that you could load the script code from a database in case 
you have it stored as such. The possibilities are endless.


As you can see, one can submit any value/object as an argument to the script and fetch any result 
of the script.


---

It would be interesting to see the above Java code transcribed to COBOL, so anyone with the 
necessary skills please give a helping hand for the community! :)


The result would be enabling COBOL programmers to invoke any kind of scripts in any kind of 
languages from COBOL exploiting the Java scripting framework.


Such scripts could e.g. dive deep into Java and serve the COBOL programs probably in an easier 
manner from then on. 

COBOL and the Java scripting framework ? (Re: Are there samples of COBOL methods or classes?

[Rony G. Flatscher]

On 28.06.2023 17:26, Tom Ross wrote:

Please check out the examples in the COBOL Programming Guide, in
Part 6. Developing object-oriented programs

GO here:https://www.ibm.com/support/pages/node/611415
Select which release you are interested in and then
click "Product Documentation"


thank you, Tom. Could get to  and from there to 
the programming guide at .


It seems that OO COBOL allows interacting with Java via JNI (Java native interface) only. 6.4 adds 
the ability to invoke static Java methods without OO COBOL.


Not having any of the necessary infrastructure (mainframe ;) , OO COBOL and Java) there is nothing I 
could do. So maybe just hinting of what would become possible if anyone with the OO COBOL-Java 
skills would come with showing how to code the following Java program in OO COBOL.


Such an example would serve as a nutshell example that would demonstrate how to invoke scripts from 
OO COBOL in any scripting language for which an implementation of javax.script.Engine exists 
including supplying arguments (stored in a Java array of type java.lang.Object) and fetching the result.


To make this as flexible (and thereby as usable) as possible, the following Java program will take 
the name of a file containing a script as a single argument, and then will load with the help of the 
Java scripting framework the appropriate scripting engine to execute the script, and supply as an 
argument the name of a Java system property which the script should return to the caller.


Here the Java code that should be transcribed to COBOL:

   import javax.script.*;
   import java.io.File;
   import java.io.FileReader;

   class Test
   {
public static void main (String args[])
{
if (args.length==0)
{
System.err.println("file name missing...");
System.exit(-1);
}
String fileName = args[0];// get filename
String extension= 
fileName.substring(fileName.lastIndexOf(".")+1);
ScriptEngineManager sem = new ScriptEngineManager();
ScriptEnginese  = sem.getEngineByExtension(extension);

Object result = null;
try
{
ScriptContext sc= se.getContext();
// add filename
sc.setAttribute(se.FILENAME, fileName  , sc.ENGINE_SCOPE);
// add some arbitrary arguments
Object scriptArgs[] = new Object [] { "first", "", "trois", null, 
"cinque" };
sc.setAttribute(se.ARGV, scriptArgs, sc.ENGINE_SCOPE);
// create a FileReader from File
FileReader f= new FileReader(new File(fileName));
result=se.eval(f);  // read and execute script
}
catch (Throwable t)
{
System.err.println("Oops, some exception occurred: "+t);
}
System.out.println("script's result: "+result);
System.exit(0);
}
   }

Here a Rexx file (can be any Rexx script):

   parse source s
   say "source :" s
   parse version v
   say "version:" v
   say "there are" arg() "arguments supplied:"
   do i=1 to arg()
   say "   #" i":" arg(i)
   end
   return 43

The Java program "Test", once compiled can then be used to run any script (not only Rexx) from a 
script file where the file extension determines which scripting language should get loaded to run 
the script in the file. Here an example of running the Java program supplying the name of a file 
containing a Rexx script:


   G:\tmp\bsf4oorexx\cobol>java Test rexxscript.rex
   REXXout>source : WindowsNT SUBROUTINE rexxscript_ori.rex
   REXXout>version: REXX-ooRexx_5.1.0(MT)_64-bit 6.05 6 Jun 2023
   REXXout>there are 6 arguments supplied:
   REXXout>   # 1: first
   REXXout>   # 2:
   REXXout>   # 3: trois
   REXXout>   # 4: The NIL object
   REXXout>   # 5: cinque
   REXXout>   # 6: a Slot.Argument
   script's result: 43

---

The script code can also be supplied directly as a String to the script engine's eval() method 
"res=eval(String scriptCode)", such that you could load the script code from a database in case you 
have it stored as such. The possibilities are endless.


As you can see, one can submit any value/object as an argument to the script and fetch any result of 
the script.


---

It would be interesting to see the above Java code transcribed to COBOL, so anyone with the 
necessary skills please give a helping hand for the community! :)


The result would be enabling COBOL programmers to invoke any kind of scripts in any kind of 
languages from COBOL exploiting the Java scripting framework.


Such scripts could e.g. dive deep into Java and serve the COBOL programs probably in an easier 
manner from then on. E.g., the following ooRexx script returns a sorted 

Re: Are there samples of COBOL methods or classes?

[Tom Ross]

Please check out the examples in the COBOL Programming Guide, in
Part 6. Developing object-oriented programs

GO here:  https://www.ibm.com/support/pages/node/611415
Select which release you are interested in and then
click "Product Documentation"

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Are there samples of COBOL methods or classes?

[Rony G Flatscher]

> Am 27.06.2023 um 19:34 schrieb Tom Ross :
> 
> 
>> 
>> As the very first computer language I learned was COBOL, I have been always=
>> interested to learn=20
>> about OO COBOL but never had the necessary time to research it.
>> 
>> Are there by any chance simple COBOL snippets that would demonstrate how to=
>> use OO COBOL to interact=20
>> with Java (e.g. creating a Java object, invoking a simple method with argum=
>> ents and fetch the=20
>> returned value) and a comparable example for COBOL 6.4?
> 
> Are the examples of OO COBOL to Java that we include in the COBOL Programming
> Guide helpful?
Probably, would you have a link to it and also to the equvalent for 6.4?

Best wishes

—-rony
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Are there samples of COBOL methods or classes?

[Tom Ross]

>As the very first computer language I learned was COBOL, I have been always=
> interested to learn=20
>about OO COBOL but never had the necessary time to research it.
>
>Are there by any chance simple COBOL snippets that would demonstrate how to=
> use OO COBOL to interact=20
>with Java (e.g. creating a Java object, invoking a simple method with argum=
>ents and fetch the=20
>returned value) and a comparable example for COBOL 6.4?

Are the examples of OO COBOL to Java that we include in the COBOL Programming
Guide helpful?

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Are there samples of COBOL methods or classes?

[Rony G. Flatscher]

As the very first computer language I learned was COBOL, I have been always interested to learn 
about OO COBOL but never had the necessary time to research it.


Are there by any chance simple COBOL snippets that would demonstrate how to use OO COBOL to interact 
with Java (e.g. creating a Java object, invoking a simple method with arguments and fetch the 
returned value) and a comparable example for COBOL 6.4?


Maybe something like interacting with the Java runtime environment like this 
(in Java):

   import javax.script.*;

   class Test
   {
public static void main (String args[])
{
ScriptEngineManager sem = new ScriptEngineManager();
ScriptEnginese  = sem.getEngineByName("rexx");
String code   = "say 'Hello world from Rexx!';\n return 43";
Object result = null;
try
{
result=se.eval(code);
}
catch (ScriptException sexc)
{
System.err.println("Oops, ScriptException occurred: "+sexc);
}
System.out.println("script's result: "+result);
System.exit(0);
}
   }

 The above program actually works if BSF4ooRexx is installed and yields:

   G:\tmp\bsf4oorexx\cobol>java Test
   REXXout>Hello world from Rexx!
   script's result: 43

The documentation of the Java scripting framework's javax.script package can be found here: 
 .


---

It would be really interesting to see how one would use OO COBOL and COBOL 6.4 to interact with the 
Java runtime environment and e.g. exploit the Java scripting framework.


---rony

P.S.: SOM has been a very interesting and exciting technology and I always have found it a little 
bit sad that it was abandoned. It was possible in the OS/2 days to subclass the WPS SOM folder class 
in Object REXX and add password access protection to it in about 15 lines of Object Rexx code, it 
was just great (and for many to this day unbelievable  how easy and how powerful that was).



On 29.05.2023 00:40, Tom Ross wrote:

Hi, While working on the earlier problems I had, I ran into the concepts=20
of COBOL Methods and Classes, and understand they can be used for Java=20
in addition to regular COBOL programs. The documentation does not=20
explain the "why" behind these or the "how" and "what", so I wonder if=20
anyone has any business case explanations of what these are or samples=20
of some COBOL-only implementations so I can see why I might want to use=20
them and how to do it?

I like to keep my COBOL current and if there is a way to use COBOL more=20
effectively, I hope you can help me understand this!


OO COBOL was added to COBOL to provide a way to communicate with Java, which
does not have programs that can be called.  Java has to run in the JVM, and
you INVOKE methods in CLASSes with Java, you do not CALL programs.  So, in
order to support this we created OO COBOL (the 2nd generation, 1st gen OO COBOL
was based on SOM if anyone remenber that in the late 1990s).  OO COBOL is only
for communicatiing for Java, unless you REALLY prefer OO programming.  The real
worl is not object oriented...we do no instantiate a customer object and then
invoke a 'send_a_bill' method on that object.  We procedurally decide that it
is time to send a cusotmer a bill and do it!

Haivng said that, we now have an easier way to allow COBOL to use Java code,
actually using the COBOL CALL statement, this new feature is available in
COBOL 6.4.  If you do not need to communicate with Java, I would not
recommend OO COBOL.  The promise of Object Oriented Programing in the 1990s
has not materialized.  Re-usable tested mehods that could be re-used to build
applications  it just not really happening!  One of my fellow IBMers left
IBM for a start up and was slinging Java all day, and found it much easier to
code new methods than to search through class libraries for pre-tested parts.

Having said all that, it was pointed out earlier that we have seample in the
COBOL Programing Guide for comunicating woith Java using OO COBOL.  OO COBOL
was not designed to be used in a pure COBOL application, so no examples of
that.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Are there samples of COBOL methods or classes?

[Seymour J Metz]

See 3.3. ::CLASS in https://www.oorexx.org/docs/rexxref/rexxref.pdf;>ooRexx Documentation 
5.0.0 Open Object Rexx Reference.

"When the only tool you have is a pipe, everything looks like a filter". 
Inheritance, like most tools, is useful in the appropriate context but is not a 
magic bullet. You can program FORTRAN in any language.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Friday, June 2, 2023 8:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Are there samples of COBOL methods or classes?

On 2/6/2023 3:47 am, Bob Bridges wrote:
> I first got the hang of oo programming using VBA, and later VBS; consequently 
> I don't think much about inheritance.  But when I finally broke down and got 
> myself a copy of ooRexx, I see the manuals have a lot to say about it.  
> Mostly I read those parts skimpily and have never yet had occasion to use 
> those features.
>
> I wonder, though, whether your objections apply as thoroughly to ooRexx as 
> they do to some other languages?  I seem to recall that ooREXX has a way of 
> specifying which methods a class inherits from other classes.  Might not that 
> obviate some of the problems?

When discussing the challenges associated with inheritance, it's worth
noting that these issues are not specific to any particular programming
language, including ooRexx. It is important to approach this topic with
the utmost respect for the language and its community, such as Rene and
Rony, who are widely recognized as talented and esteemed individuals in
the ooRexx space. Everyone in this forum is well aware of my thoughts
and opinions regarding REXX.

In the early 1990s, the challenges associated with inheritance had
already been recognized within the software development community. At
that time, a group of IBMers, known as the Gang of Four (GoF), authored
a groundbreaking book titled "Design Patterns." This seminal work
tackled the inheritance problem head-on by offering reusable design
patterns as solutions. Even today, this book remains an invaluable
resource that I personally refer to, considering it a true masterpiece.

https://en.wikipedia.org/wiki/Design_Patterns

The key point "Prefer composition over inheritance" is a principle in
software design that suggests using object composition instead of class
inheritance. It promotes flexibility, code reuse, and maintainability.

Composition involves combining simpler components to create more complex
objects, allowing for greater flexibility and modularity. It reduces
coupling between classes and promotes loose dependencies, making it
easier to modify or extend functionality without affecting other parts
of the codebase.

By favoring composition, code reusability improves as smaller components
can be reused in different configurations. Encapsulation and
interface-driven design are emphasized, leading to modular and
interchangeable implementations.

Composition helps separate concerns by dividing complex functionality
into smaller, specialized components. This improves code readability,
testability, and maintainability.

While inheritance still has its uses, the principle encourages
developers to consider composition as the default approach for achieving
flexible and maintainable designs. It's worth noting that some modern
languages, such as Rust and Go, do not support inheritance, effectively
enforcing this principle.


>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Question:  Would you rather raise a child who grows up to be (a) an 
> honest, ethical, family-centered person who works on an assembly line or (b) 
> a habitually dishonest, amoral narcissist who is the CEO of a big 
> corporation?  If your answer is (a), then answer this:  Which child would you 
> brag about more?  -John K Resemond, "Who's in Charge Around Here?"; United 
> Airlines' magazine "Hemispheres", Sep 1999 */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> David Crayford
> Sent: Thursday, June 1, 2023 07:25
>
> I totally agree that Object-Oriented (OO) programming hasn't lived up to all 
> the hype it once had. But I have to disagree with the idea that code reuse is 
> the only purpose of OO. It's actually more nuanced than that.
> However, if we're talking about code reuse and Java, just take a look at the 
> Maven central repository. It's got a whopping 400,000 unique artifacts and 
> handles a mind-blowing 70 million downloads every year.
> Now that's some serious code reuse, and it's all thanks to the open-source 
> community. Pretty amazing, huh?
>
> I think a lot of the misunderstanding about OO is related to inheritance 
> which was popular in the

Re: Are there samples of COBOL methods or classes?

[David Crayford]

On 2/6/2023 3:47 am, Bob Bridges wrote:

I first got the hang of oo programming using VBA, and later VBS; consequently I 
don't think much about inheritance.  But when I finally broke down and got 
myself a copy of ooRexx, I see the manuals have a lot to say about it.  Mostly 
I read those parts skimpily and have never yet had occasion to use those 
features.

I wonder, though, whether your objections apply as thoroughly to ooRexx as they 
do to some other languages?  I seem to recall that ooREXX has a way of 
specifying which methods a class inherits from other classes.  Might not that 
obviate some of the problems?


When discussing the challenges associated with inheritance, it's worth 
noting that these issues are not specific to any particular programming 
language, including ooRexx. It is important to approach this topic with 
the utmost respect for the language and its community, such as Rene and 
Rony, who are widely recognized as talented and esteemed individuals in 
the ooRexx space. Everyone in this forum is well aware of my thoughts 
and opinions regarding REXX.


In the early 1990s, the challenges associated with inheritance had 
already been recognized within the software development community. At 
that time, a group of IBMers, known as the Gang of Four (GoF), authored 
a groundbreaking book titled "Design Patterns." This seminal work 
tackled the inheritance problem head-on by offering reusable design 
patterns as solutions. Even today, this book remains an invaluable 
resource that I personally refer to, considering it a true masterpiece.


https://en.wikipedia.org/wiki/Design_Patterns

The key point "Prefer composition over inheritance" is a principle in 
software design that suggests using object composition instead of class 
inheritance. It promotes flexibility, code reuse, and maintainability.


Composition involves combining simpler components to create more complex 
objects, allowing for greater flexibility and modularity. It reduces 
coupling between classes and promotes loose dependencies, making it 
easier to modify or extend functionality without affecting other parts 
of the codebase.


By favoring composition, code reusability improves as smaller components 
can be reused in different configurations. Encapsulation and 
interface-driven design are emphasized, leading to modular and 
interchangeable implementations.


Composition helps separate concerns by dividing complex functionality 
into smaller, specialized components. This improves code readability, 
testability, and maintainability.


While inheritance still has its uses, the principle encourages 
developers to consider composition as the default approach for achieving 
flexible and maintainable designs. It's worth noting that some modern 
languages, such as Rust and Go, do not support inheritance, effectively 
enforcing this principle.





---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Question:  Would you rather raise a child who grows up to be (a) an honest, ethical, 
family-centered person who works on an assembly line or (b) a habitually dishonest, amoral 
narcissist who is the CEO of a big corporation?  If your answer is (a), then answer this:  Which 
child would you brag about more?  -John K Resemond, "Who's in Charge Around Here?"; 
United Airlines' magazine "Hemispheres", Sep 1999 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Thursday, June 1, 2023 07:25

I totally agree that Object-Oriented (OO) programming hasn't lived up to all 
the hype it once had. But I have to disagree with the idea that code reuse is 
the only purpose of OO. It's actually more nuanced than that.
However, if we're talking about code reuse and Java, just take a look at the 
Maven central repository. It's got a whopping 400,000 unique artifacts and 
handles a mind-blowing 70 million downloads every year.
Now that's some serious code reuse, and it's all thanks to the open-source 
community. Pretty amazing, huh?

I think a lot of the misunderstanding about OO is related to inheritance which 
was popular in the 90's but not so much now now. Inheritance is not inherently 
bad in OOP, but it can have drawbacks when misused or overused. Here are a few 
reasons why it can be problematic:

  1. Tight Coupling: Inheritance creates a strong connection between
 classes, making changes in the base class impact all its subclasses,
 which can make the code fragile and less flexible.

  2. Inappropriate Subclassing: Using inheritance when it's not suitable
 can lead to confusing and convoluted code that is hard to understand.

  3. Complexity: Large inheritance hierarchies can become complex and
 difficult to manage, leading to maintenance issues.

  4. Code Duplication and Rigidity: Inheritance can result in code
 duplication and make it challenging to modify the base class or
 rearrange the hierarchy.

  5. Limited Reusability: Inheritance can restrict code 

Re: Are there samples of COBOL methods or classes?

[Jon Butler]

Not to put too fine a point on encapsulation because what you say is true for 
Working-Storage and Paragraphs or Sections.  But you can restrict or make 
variables available to internal subroutines with the GLOBAL attribute.  
Likewise, variables can be made available to external subroutines with the 
EXTERNAL attribute.  

Either fortunately or unfortunately, depending on your requirement, EXTERNAL 
does not imply GLOBAL. 

Cheers,

Jon.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Are there samples of COBOL methods or classes?

[Bob Bridges]

I first got the hang of oo programming using VBA, and later VBS; consequently I 
don't think much about inheritance.  But when I finally broke down and got 
myself a copy of ooRexx, I see the manuals have a lot to say about it.  Mostly 
I read those parts skimpily and have never yet had occasion to use those 
features.

I wonder, though, whether your objections apply as thoroughly to ooRexx as they 
do to some other languages?  I seem to recall that ooREXX has a way of 
specifying which methods a class inherits from other classes.  Might not that 
obviate some of the problems?

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Question:  Would you rather raise a child who grows up to be (a) an honest, 
ethical, family-centered person who works on an assembly line or (b) a 
habitually dishonest, amoral narcissist who is the CEO of a big corporation?  
If your answer is (a), then answer this:  Which child would you brag about 
more?  -John K Resemond, "Who's in Charge Around Here?"; United Airlines' 
magazine "Hemispheres", Sep 1999 */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Thursday, June 1, 2023 07:25

I totally agree that Object-Oriented (OO) programming hasn't lived up to all 
the hype it once had. But I have to disagree with the idea that code reuse is 
the only purpose of OO. It's actually more nuanced than that. 
However, if we're talking about code reuse and Java, just take a look at the 
Maven central repository. It's got a whopping 400,000 unique artifacts and 
handles a mind-blowing 70 million downloads every year. 
Now that's some serious code reuse, and it's all thanks to the open-source 
community. Pretty amazing, huh?

I think a lot of the misunderstanding about OO is related to inheritance which 
was popular in the 90's but not so much now now. Inheritance is not inherently 
bad in OOP, but it can have drawbacks when misused or overused. Here are a few 
reasons why it can be problematic:

 1. Tight Coupling: Inheritance creates a strong connection between
classes, making changes in the base class impact all its subclasses,
which can make the code fragile and less flexible.

 2. Inappropriate Subclassing: Using inheritance when it's not suitable
can lead to confusing and convoluted code that is hard to understand.

 3. Complexity: Large inheritance hierarchies can become complex and
difficult to manage, leading to maintenance issues.

 4. Code Duplication and Rigidity: Inheritance can result in code
duplication and make it challenging to modify the base class or
rearrange the hierarchy.

 5. Limited Reusability: Inheritance can restrict code reusability by
tightly binding subclasses to their base class, limiting their use
in different contexts.

It's crucial to use inheritance judiciously and consider alternative approaches 
when appropriate to avoid these potential drawbacks. Modern languages such as 
Go and Rust do not support inheritance. They support interfaces (traits) which 
are fundamental for polymorphism.

Polymorphism reduces the need for extensive if-else logic by allowing different 
objects to respond to the same method call in different ways. 
Instead of using if-else statements to check the type of an object and perform 
specific actions, polymorphism enables us to define common methods in a 
superclass or interface and rely on the specific implementations in subclasses.

No need to define encapsulation (data hiding) as we all know what that is. The 
WORKING-STORAGE section in COBOL really highlights the stark differences 
between COBOL and modern languages. In COBOL, all data, including loop indexes 
used within a routine, are global. Nowadays, this global scope for data makes 
me quite uncomfortable, especially when I'm accustomed to being able to declare 
variables within specific blocks like for loops or if statements. 
Unfortunately, COBOL doesn't excel in terms of lexical scoping, which is a 
strong point in modern programming languages.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Are there samples of COBOL methods or classes?

[David Crayford]

I totally agree that Object-Oriented (OO) programming hasn't lived up to 
all the hype it once had. But I have to disagree with the idea that code 
reuse is the only purpose of OO. It's actually more nuanced than that. 
However, if we're talking about code reuse and Java, just take a look at 
the Maven central repository. It's got a whopping 400,000 unique 
artifacts and handles a mind-blowing 70 million downloads every year. 
Now that's some serious code reuse, and it's all thanks to the 
open-source community. Pretty amazing, huh?


I think a lot of the misunderstanding about OO is related to inheritance 
which was popular in the 90's but not so much now now. Inheritance is 
not inherently bad in OOP, but it can have drawbacks when misused or 
overused. Here are a few reasons why it can be problematic:


1.

   Tight Coupling: Inheritance creates a strong connection between
   classes, making changes in the base class impact all its subclasses,
   which can make the code fragile and less flexible.

2.

   Inappropriate Subclassing: Using inheritance when it's not suitable
   can lead to confusing and convoluted code that is hard to understand.

3.

   Complexity: Large inheritance hierarchies can become complex and
   difficult to manage, leading to maintenance issues.

4.

   Code Duplication and Rigidity: Inheritance can result in code
   duplication and make it challenging to modify the base class or
   rearrange the hierarchy.

5.

   Limited Reusability: Inheritance can restrict code reusability by
   tightly binding subclasses to their base class, limiting their use
   in different contexts.

It's crucial to use inheritance judiciously and consider alternative 
approaches when appropriate to avoid these potential drawbacks. Modern 
languages such as Go and Rust do not support inheritance. They support 
interfaces (traits) which are fundamental for polymorphism.


Polymorphism reduces the need for extensive if-else logic by allowing 
different objects to respond to the same method call in different ways. 
Instead of using if-else statements to check the type of an object and 
perform specific actions, polymorphism enables us to define common 
methods in a superclass or interface and rely on the specific 
implementations in subclasses.


No need to define encapsulation (data hiding) as we all know what that 
is. The WORKING-STORAGE section in COBOL really highlights the stark 
differences between COBOL and modern languages. In COBOL, all data, 
including loop indexes used within a routine, are global. Nowadays, this 
global scope for data makes me quite uncomfortable, especially when I'm 
accustomed to being able to declare variables within specific blocks 
like for loops or if statements. Unfortunately, COBOL doesn't excel in 
terms of lexical scoping, which is a strong point in modern programming 
languages.


On 29/5/2023 6:40 am, Tom Ross wrote:

Hi, While working on the earlier problems I had, I ran into the concepts=20
of COBOL Methods and Classes, and understand they can be used for Java=20
in addition to regular COBOL programs. The documentation does not=20
explain the "why" behind these or the "how" and "what", so I wonder if=20
anyone has any business case explanations of what these are or samples=20
of some COBOL-only implementations so I can see why I might want to use=20
them and how to do it?

I like to keep my COBOL current and if there is a way to use COBOL more=20
effectively, I hope you can help me understand this!


OO COBOL was added to COBOL to provide a way to communicate with Java, which
does not have programs that can be called.  Java has to run in the JVM, and
you INVOKE methods in CLASSes with Java, you do not CALL programs.  So, in
order to support this we created OO COBOL (the 2nd generation, 1st gen OO COBOL
was based on SOM if anyone remenber that in the late 1990s).  OO COBOL is only
for communicatiing for Java, unless you REALLY prefer OO programming.  The real
worl is not object oriented...we do no instantiate a customer object and then
invoke a 'send_a_bill' method on that object.  We procedurally decide that it
is time to send a cusotmer a bill and do it!

Haivng said that, we now have an easier way to allow COBOL to use Java code,
actually using the COBOL CALL statement, this new feature is available in
COBOL 6.4.  If you do not need to communicate with Java, I would not
recommend OO COBOL.  The promise of Object Oriented Programing in the 1990s
has not materialized.  Re-usable tested mehods that could be re-used to build
applications  it just not really happening!  One of my fellow IBMers left
IBM for a start up and was slinging Java all day, and found it much easier to
code new methods than to search through class libraries for pre-tested parts.

Having said all that, it was pointed out earlier that we have seample in the
COBOL Programing Guide for comunicating woith Java using OO COBOL.  OO COBOL
was not designed to be used in a pure COBOL application, so no 

Re: Are there samples of COBOL methods or classes?

[Charles Mills]

Wait a minute! Reusability of code and Object Orientation are totally different 
things!

One might have a library of reusable COBOL subroutines that programmers could 
cut and paste into their programs. (Or that worked in some other way.) No 
object orientation necessary.

And there are lots of real-world problems that lend themselves to object 
orientation. I am working on a C++ program at this moment that writes Rexx stem 
variables via IRXEXCOM. It implements the common convention in which STEM.0 
contains a count and STEM.n contains related records of some sort. I 
instantiate it with a particular stem name. (Thus I can be creating any number 
of differently named stems in parallel.) It has a put() method that 
instantiates an SHVBLOCK class to hold the one record being put. It increments 
the count. It has a finalize() method that calls IRXEXCOM to write the Rexx 
variables including STEM.0. Is that not a real-world problem?

Charles

On Sun, 28 May 2023 15:40:28 -0700, Tom Ross  
wrote:

>The real worl[d] is not object oriented

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Are there samples of COBOL methods or classes?

[Seymour J Metz]

Yeah, and then they blame me when they modify the code that they copied and it 
no longer works, or when it still does what I originally wanted it to do but 
not what they wanted. Code reuse is a good servant but a bad master.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
rpinion865 [042a019916dd-dmarc-requ...@listserv.ua.edu]
Sent: Monday, May 29, 2023 4:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Are there samples of COBOL methods or classes?

When I started in 1980, we used 'objects' by copying the last similar program 
from someone else 's library.

Sent from Proton Mail mobile

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Are there samples of COBOL methods or classes?

[rpinion865]

When I started in 1980, we used 'objects' by copying the last similar program 
from someone else 's library.

Sent from Proton Mail mobile

 Original Message 
On May 29, 2023, 9:47 AM, Andrew Rowley wrote:

> On 29/05/2023 8:40 am, Tom Ross wrote: > ... The real > worl is not object 
> oriented...we do no instantiate a customer object and then > invoke a 
> 'send_a_bill' method on that object. We procedurally decide that it > is time 
> to send a cusotmer a bill and do it! I'm not sure I would agree... it 
> probably depends on what sort of code you work with, but I think it would be 
> extremely common to have a customer object and to have a bill object. Then 
> e.g. you might have dozens of ways line items might be added to a bill, but 
> the bill checks its status when you try to add an item and won't allow it if 
> the bill has already been sent. A program always has a sequence of actions 
> i.e. a procedure, but with well designed object classes you don't need to 
> know the procedures beforehand. > Re-usable tested mehods that could be 
> re-used to build > applications it just not really happening! It's happening 
> a lot! -- Andrew Rowley Black Hill Software 
> -- For 
> IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Are there samples of COBOL methods or classes?

[Andrew Rowley]

On 29/05/2023 8:40 am, Tom Ross wrote:

...  The real
worl is not object oriented...we do no instantiate a customer object and then
invoke a 'send_a_bill' method on that object.  We procedurally decide that it
is time to send a cusotmer a bill and do it!


I'm not sure I would agree... it probably depends on what sort of code 
you work with, but I think it would be extremely common to have a 
customer object and to have a bill object. Then e.g. you might have 
dozens of ways line items might be added to a bill, but the bill checks 
its status when you try to add an item and won't allow it if the bill 
has already been sent.


A program always has a sequence of actions i.e. a procedure, but with 
well designed object classes you don't need to know the procedures 
beforehand.



  Re-usable tested mehods that could be re-used to build
applications  it just not really happening!


It's happening a lot!

--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Are there samples of COBOL methods or classes?

[Tom Ross]

>Hi, While working on the earlier problems I had, I ran into the concepts=20
>of COBOL Methods and Classes, and understand they can be used for Java=20
>in addition to regular COBOL programs. The documentation does not=20
>explain the "why" behind these or the "how" and "what", so I wonder if=20
>anyone has any business case explanations of what these are or samples=20
>of some COBOL-only implementations so I can see why I might want to use=20
>them and how to do it?
>
>I like to keep my COBOL current and if there is a way to use COBOL more=20
>effectively, I hope you can help me understand this!


OO COBOL was added to COBOL to provide a way to communicate with Java, which
does not have programs that can be called.  Java has to run in the JVM, and
you INVOKE methods in CLASSes with Java, you do not CALL programs.  So, in
order to support this we created OO COBOL (the 2nd generation, 1st gen OO COBOL
was based on SOM if anyone remenber that in the late 1990s).  OO COBOL is only
for communicatiing for Java, unless you REALLY prefer OO programming.  The real
worl is not object oriented...we do no instantiate a customer object and then
invoke a 'send_a_bill' method on that object.  We procedurally decide that it
is time to send a cusotmer a bill and do it!

Haivng said that, we now have an easier way to allow COBOL to use Java code,
actually using the COBOL CALL statement, this new feature is available in
COBOL 6.4.  If you do not need to communicate with Java, I would not
recommend OO COBOL.  The promise of Object Oriented Programing in the 1990s
has not materialized.  Re-usable tested mehods that could be re-used to build
applications  it just not really happening!  One of my fellow IBMers left
IBM for a start up and was slinging Java all day, and found it much easier to
code new methods than to search through class libraries for pre-tested parts.

Having said all that, it was pointed out earlier that we have seample in the
COBOL Programing Guide for comunicating woith Java using OO COBOL.  OO COBOL
was not designed to be used in a pure COBOL application, so no examples of
that.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Are there samples of COBOL methods or classes?

[Sri h Kolusu]

>> The documentation does not explain the "why" behind these or the "how" and 
>> "what",

Billy,

The chapter 35(Writing object-oriented programs) in the application programming 
guide is a good place to start.

https://www.ibm.com/docs/en/cobol-zos/6.4?topic=programs-writing-object-oriented

And here is an example program.

https://www.ibm.com/docs/en/cobol-zos/6.4?topic=method-example-defining

Thanks,
Kolusu


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Are there samples of COBOL methods or classes?

[Billy Ashton]

Hi, While working on the earlier problems I had, I ran into the concepts 
of COBOL Methods and Classes, and understand they can be used for Java 
in addition to regular COBOL programs. The documentation does not 
explain the "why" behind these or the "how" and "what", so I wonder if 
anyone has any business case explanations of what these are or samples 
of some COBOL-only implementations so I can see why I might want to use 
them and how to do it?


I like to keep my COBOL current and if there is a way to use COBOL more 
effectively, I hope you can help me understand this!


Thank you and best regards,
Billy Ashton

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN