Cobol - Re: Java compatibility issues (WAS: MF having issues?)

Author

Re: Java compatibility issues (WAS: MF having issues?)

Frank Swarbrick

2006-03-07, 6:56 pm

William M. Klein<wmklein@nospam.netcom.com> 03/03/06 11:26 PM >>>
>"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
>news:46sb84Fcgn9iU3@individual.net...
><snip>
child...)[color=darkred]
>
>Frank,
> If you aren't aware, the '02 COBOL Standard allows
>
>Move myoBJECT::"MyMethod" (myParm) to MyResult
>
>which seems pretty much like the 2nd example you gave.
>
>For the "COBOL-thinker"
> INVOKE is to CALL
> as
> inline object invocation (ussing "::" operator) is to user-defined
functions
>
>(both of the latter features are fully supported in the '02 COBOL Standard,
but
>not in all that many existing implementations)

Actually, I was aware of that. But most of the examples I see here use the
long form, and I also didn't see any mention of the short form in the
Enterprise COBOL docs, so...

Is there a short form for a regular function call? EG: move myfunc (parm1,
parm2) to myresult ? I have the 2002 standard at home, but I can't recall.

By the way, can someone explain the reason for the quotes around the method
name? Seems superfluous, except perhaps to separate the object name from
the method name and the parameters.

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

Michael Wojcik

2006-03-08, 6:55 pm

In article <476delFe2lamU2@individual.net>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
>
> By the way, can someone explain the reason for the quotes around the method
> name? Seems superfluous, except perhaps to separate the object name from
> the method name and the parameters.

Same reason why you need them around a literal program name in a call
statement. The method name can be a data-item as well as a literal:

move "myMethod" to method-name
invoke myObject method-name ...

This is actually quite different from the C-derived languages, which
support *neither* of those name-resolution methods directly. In C,
for example, a called function can only be specified using a variable
of a function-pointer type, or the name of a function - which is
actually the name of a function-type variable, and decays to a
pointer-to-function-type variable in most contexts. (Function-type
variables in C are immutable, so "variable" is a bit of a misnomer,
but from the language's point of view that's what they are.)

C-derived languages thus require other mechanisms to call a function
using a name determined at run-time, and in fact there's no standard
way to do that in C.

Thus in Java you write:

myObject.myMethod(...);

because you can't write:

String myMethodName = "myMethod";
myObject.myMethodName(...);

But in COBOL, in effect, you can do the latter, so it has to be
distinguished from the equivalent of the former.

--
Michael Wojcik michael.wojcik@microfocus.com

As always, great patience and a clean work area are required for fulfillment
of this diversion, and it should not be attempted if either are compromised.
-- Chris Ware

James J. Gavan

2006-03-09, 3:55 am

Michael Wojcik wrote:

> In article <476delFe2lamU2@individual.net>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
>

Frank,

Good stuff from Michael. But just to re-iterate, at least in M/F
products, both the following are acceptable :-

method-id. myMethodname.
method-id. 'myMethodname'. *> or double-quotes

An even niftier feature using method literals is :-

01 MethodTableA.
05 pic x(40) value "useThisOne".
05 pic x(40) value "thisSecondOne".
05 pic x(40) value "andAThird".
05 ......
01 MethodTableB redefines MethodTableA.
05 MethodName pic x(40) occurs ??.

Evaluate true
when MyResult < 10 invoke MyObject using Methodname(1)
when MyResult < 20 invoke MyObject using Methodname(2)
when etc......

You can't do it, but in M/F, (a very old extension - well it wasn't when
it started out - but too long a story to tell), I can localize those
Method Tables above to the WORKING-STORAGE SECTION of a method which is
doing the above EVALUATE. That is, the Method could contain both a
Working-Storage Section (so that the literal values don't disappear when
you exit the method) plus a Local-Storage Section, if necessary. In
practical terms just put the localized variables under the same W/S
heading; ignore Local-Storage Section.

Jimmy
[color=darkred]
> Same reason why you need them around a literal program name in a call
> statement. The method name can be a data-item as well as a literal:
>
> move "myMethod" to method-name
> invoke myObject method-name ...
>
> This is actually quite different from the C-derived languages, which
> support *neither* of those name-resolution methods directly. In C,
> for example, a called function can only be specified using a variable
> of a function-pointer type, or the name of a function - which is
> actually the name of a function-type variable, and decays to a
> pointer-to-function-type variable in most contexts. (Function-type
> variables in C are immutable, so "variable" is a bit of a misnomer,
> but from the language's point of view that's what they are.)
>
> C-derived languages thus require other mechanisms to call a function
> using a name determined at run-time, and in fact there's no standard
> way to do that in C.
>
> Thus in Java you write:
>
> myObject.myMethod(...);
>
> because you can't write:
>
> String myMethodName = "myMethod";
> myObject.myMethodName(...);
>
> But in COBOL, in effect, you can do the latter, so it has to be
> distinguished from the equivalent of the former.
>

William M. Klein

2006-03-09, 3:55 am

My memory was fuzzy on this, but checking the final '02 Standard, you may use an
identifier for the method name but ONLY when the object reference is a
"universal object reference".

--
Bill Klein
wmklein <at> ix.netcom.com
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:d7OPf.128758$B94.19177@pd7tw3no...[color=darkred]
> Michael Wojcik wrote:
>
>
> Frank,
>
> Good stuff from Michael. But just to re-iterate, at least in M/F products,
> both the following are acceptable :-
>
> method-id. myMethodname.
> method-id. 'myMethodname'. *> or double-quotes
>
> An even niftier feature using method literals is :-
>
> 01 MethodTableA.
> 05 pic x(40) value "useThisOne".
> 05 pic x(40) value "thisSecondOne".
> 05 pic x(40) value "andAThird".
> 05 ......
> 01 MethodTableB redefines MethodTableA.
> 05 MethodName pic x(40) occurs ??.
>
> Evaluate true
> when MyResult < 10 invoke MyObject using Methodname(1)
> when MyResult < 20 invoke MyObject using Methodname(2)
> when etc......
>
> You can't do it, but in M/F, (a very old extension - well it wasn't when it
> started out - but too long a story to tell), I can localize those Method
> Tables above to the WORKING-STORAGE SECTION of a method which is doing the
> above EVALUATE. That is, the Method could contain both a Working-Storage
> Section (so that the literal values don't disappear when you exit the method)
> plus a Local-Storage Section, if necessary. In practical terms just put the
> localized variables under the same W/S heading; ignore Local-Storage Section.
>
> Jimmy
>

Michael Wojcik

2006-03-09, 6:55 pm

In article <HqPPf.42770$x96.17882@fe02.news.easynews.com>, "William M. Klein" <wmklein@nospam.netcom.com> writes:
> My memory was fuzzy on this, but checking the final '02 Standard, you may use an
> identifier for the method name but ONLY when the object reference is a
> "universal object reference".

Looks like that's the case. I missed that when I checked the INVOKE
syntax for my previous post; thanks for picking it up. ("Universal"
references are ones with no object type information. So when you
invoke a method using a data- item, the compiler can't check for
interface conformance.)

Still, that doesn't affect my basic point, which is that the quotes
are necessary to distinguish between literal and data-item method
names.

--
Michael Wojcik michael.wojcik@microfocus.com

We are subdued to what we work in. (E M Forster)

Sponsored Links