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

Author

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

Frank Swarbrick

2006-03-10, 6:55 pm

>
>
>
>In article <4793b3FekqcoU1@individual.net>, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> writes:
tried[color=darkred]
>
>Right, but there's the extra indirection of creating a Class object
>and a Method object and so forth. (This is what there's no standard
>for in C. There *is* a standard way to do it in Java, as you've just
>described.)
>
>COBOL, on the other hand, has syntactic sugar to do the "look this
>name up and resolve it to the code I want to call" bit, right in the
>CALL or INVOKE verb.

The COBOL way is easier to code and to understand, no doubt. Don't know if
there are any specific advantages to the Java way.

>Languages with first-class functions, like Scheme and OCaml, have yet
>another variation on this: you can have function names and function
>variables and functions you compute at runtime, and you can pass
>functions as parameters and return new functions. They're even more
>flexible when it comes to invoking functions and methods because the
>thing they're invoking may not have existed until right before the
>invocation.

You lost me! :-) (Don't bother trying to elaborate. I'll have to read up
on functional programming before trying to make sense of it.)

Frank

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

Michael Wojcik

2006-03-10, 6:55 pm

In article <47docfFf100vU1@individual.net>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> writes:
>
> The COBOL way is easier to code and to understand, no doubt. Don't know if
> there are any specific advantages to the Java way.

Well, the C/Java way does give you more control. You know whether
you're calling a method (or function, depending on the language) that
was specified at compilation time, or something that the runtime
needs to go out and find. (This may not be strictly true in all C
implementations, because so much is unspecified by the standard.)
With COBOL, CALL "name" hides that distinction, which is convenient
if you don't care, but troublesome if you do.

For example, if I mean to call "foo" in my COBOL program, but type "fo"
by mistake, I won't know about that error unless and until my program
happens to go down that code path at runtime.

>
> You lost me! :-) (Don't bother trying to elaborate. I'll have to read up
> on functional programming before trying to make sense of it.)

I suspect you'd like it. You might not want to use it professionally,
but people who are interested in programming languages generally find
functional programming entertaining (and often enlightening), at least.

--
Michael Wojcik michael.wojcik@microfocus.com

You have Sun saying, "Who needs Linux? We have Solaris." You have
Microsoft saying, "Who needs Linux? We have Windows 2000." Then you
have IBM saying, "I think we all need Linux." Only the greatest
sinners know how to really repent. -- John Patrick, IBM VP

William M. Klein

2006-03-12, 3:55 am

>Michael Wojcik" <mwojcik@newsguy.com> wrote in message
>news:dushcq01s5v@news1.newsguy.com...
>
<snip>
> Well, the C/Java way does give you more control. You know whether
> you're calling a method (or function, depending on the language) that
> was specified at compilation time, or something that the runtime
> needs to go out and find. (This may not be strictly true in all C
> implementations, because so much is unspecified by the standard.)
> With COBOL, CALL "name" hides that distinction, which is convenient
> if you don't care, but troublesome if you do.
>
> For example, if I mean to call "foo" in my COBOL program, but type "fo"
> by mistake, I won't know about that error unless and until my program
> happens to go down that code path at runtime.
>

Michael,
Check out the "Call prototype" (and function prototypes) defined in the '02
ISO Standard. This allows for compile-time checking via the repository. I
don't know if it is EXACTLY like that of other languages, but certainly does
catch many of these types of problems at compile-time.

--
Bill Klein
wmklein <at> ix.netcom.com

Michael Wojcik

2006-03-12, 6:55 pm

In article <XjOQf.120427$TK5.3479@fe06.news.easynews.com>, "William M. Klein" <wmklein@nospam.netcom.com> writes:
>
> Check out the "Call prototype" (and function prototypes) defined in the '02
> ISO Standard. This allows for compile-time checking via the repository. I
> don't know if it is EXACTLY like that of other languages, but certainly does
> catch many of these types of problems at compile-time.

Yes, I was ignoring prototypes for simplicity, since they're optional
and not widely used in my experience (though I think they're a good
idea). They don't help with calling a program that's specified using
a data-item, in any case, since that'd have to be checked at run
time, but they do help with compile-time checking of calling using a
literal name.

And actually they don't handle this particular case, where there's a
typo in the name, because the compiler will just note that there's no
entry for that program in the repository and assume the programmer
knows what he's doing. I think that's true, anyway; I haven't studied
exactly what the Standard says about prototypes. (I know that it
requires that implementations provide an option to flag prototype
violations. I don't know if that includes flagging calls to non-
prototyped programs.)

--
Michael Wojcik michael.wojcik@microfocus.com

Pogo: The dogs *scarcely* ever catches the rabbit.
Bun: "Scarcely" got a very unpleasant ring of frequency to it.
-- Walt Kelly

James J. Gavan

2006-03-13, 6:55 pm

Michael Wojcik wrote:
> In article <XjOQf.120427$TK5.3479@fe06.news.easynews.com>, "William M. Klein" <wmklein@nospam.netcom.com> writes:
>
>
>
> Yes, I was ignoring prototypes for simplicity, since they're optional
> and not widely used in my experience (though I think they're a good
> idea). They don't help with calling a program that's specified using
> a data-item, in any case, since that'd have to be checked at run
> time, but they do help with compile-time checking of calling using a
> literal name.
>
> And actually they don't handle this particular case, where there's a
> typo in the name, because the compiler will just note that there's no
> entry for that program in the repository and assume the programmer
> knows what he's doing. I think that's true, anyway; I haven't studied
> exactly what the Standard says about prototypes. (I know that it
> requires that implementations provide an option to flag prototype
> violations. I don't know if that includes flagging calls to non-
> prototyped programs.)
>
Michael,

I may completely have the wrong end of the stick, and I don't have N/E
4.0 to test with. I can't be certain but if you have a method typo 'fo'
instead of 'foo', my understanding is that the compile of your current
program, which includes a reference to Foo-Class in Repository, will
forward check to see if method "foo" exists, (or 'fo' is non-existent as
in your example). If the logic of what I've written is correct, then you
get forward-checking for each compile where you are perhaps building an
hierarchy. Of course you can build an empty Foo-Class, i.e. with named
empty methods, (even dummy sending and receiving linkage), so that the
next class, 'down the line' is able to be compiled.

Confirm with one of your fellow-boffins :-)

Jimmy

Sponsored Links