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

Sergey Kashyrin wrote:
> Oliver,
>
> 
Sergey,

I didn't ask Oliver to comment because I wanted to stir the *proverbial*
with a big wooden spoon - I have a possible hobbyist interest but need
to get a handle on say using Java versus C#.

Bit easier with COBOL 'cos we talk about COBOL '68, '74, '85 etc., so we
see the time frame from the designations. Without going all detailed,
can you take the Java Version Numbers you quoted and give us a year for
each so that we can see the time spans between ?

Jimmy, Calgary AB

On Sat, 4 Mar 2006 14:04:23 -0500, "charles hottel"
<jghottel@yahoo.com> wrote:

> All of the
>other languages have extensive standard libraries and COBOL does not.  Even
>C which is not OO has a standard library. I think the OO paradigm encourage
s
>and promotes the building of these libraries.  There is no inherent reason
>why COBOL could not have standard libraries that perform the same functions
>that other languages have, but for the most part it does not.

There are library based languages, and there are languages that are
not based upon libraries.

Library based languages are open ended - I don't know anybody who
knows a library the way many people know a language like CoBOL.

Of course, we can make our CoBOL environment work just like library
languages.   This is done with OO CoBOL, and can be done with any
CoBOL.   Buy a standard library and use it from CoBOL.

We can buy libraries and add them to C environments as well.   Or code
them.

On Sun, 5 Mar 2006 16:21:56 +1300, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:
 
>
>Well, you got me there :-) I used floating point (COMP-1 and COMP-2) for
>many years on the mainframe and always considered it to be binary; not sure
>what you mean by Hex floating point. (Hex is simply a shorthand
>representation of binary...).

I don't recall ever using floating point with CoBOL in a real
environment.

Howard Brazee wrote:
> On Sat, 4 Mar 2006 14:04:23 -0500, "charles hottel"
> <jghottel@yahoo.com> wrote:
>
> 
>
>
> There are library based languages, and there are languages that are
> not based upon libraries.
>
> Library based languages are open ended - I don't know anybody who
> knows a library the way many people know a language like CoBOL.
>
> Of course, we can make our CoBOL environment work just like library
> languages.   This is done with OO CoBOL, and can be done with any
> CoBOL.   Buy a standard library and use it from CoBOL.

Perhaps, confined to your own particular environment on big iron. It is
just not going to happen with us PC-guys. As somebody has already
pointed out, perhaps this thread or elsewhere, you are an employee using
your boss'es machine. What you write while on his payroll is his.

I haven't seen any interest at the PC-Level within the M/F family.
Ignoring runtime fees. If Pete and Donald were to write classes in
Fujitsu OO and I did the same in Micro Focus, there's no way we can swap
them at the source level for recompilation. GUIs and Collections -
entirely different. Doesn't leave too much else that could be of
significant benefit.

For PCs - there's standard Procedural COBOL but not OO COBOL.

Jimmy

> We can buy libraries and add them to C environments as well.   Or code
> them.

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:zw6Pf.112723$H%4.20576@pd7tw2no...
> Howard Brazee wrote: 
>
> Perhaps, confined to your own particular environment on big iron. It is
> just not going to happen with us PC-guys. As somebody has already pointed
> out, perhaps this thread or elsewhere, you are an employee using your
> boss'es machine. What you write while on his payroll is his.
>
> I haven't seen any interest at the PC-Level within the M/F family.
> Ignoring runtime fees. If Pete and Donald were to write classes in Fujitsu
> OO and I did the same in Micro Focus, there's no way we can swap them at
> the source level for recompilation. GUIs and Collections - entirely
> different. Doesn't leave too much else that could be of significant
> benefit.
>
I'm not so sure, but I wouldn't want to do it and I agree it would be more
difficult than it ought to be... Of course, given my stated position on
source maintenance of components, I wouldn't personally be concerned about
recompiling them from source anyhow. The solution would be to wrap them as
ActiveX or COM components then they COULD be exchanged. GUIs are not so
different, it's just that you seem to be dealing with them at a much lower
level than I would expect. Nothing wrong with that, but it is time
consumiong and a lot of work. On the other hand, it does give you complete
control and insight into exactly how a given control works. I'd still favour
a control library of components that oun can simply driop onto a form or
desktop.

Pete.

Pete Dashwood wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
\>
> I'm not so sure, but I wouldn't want to do it and I agree it would be more
> difficult than it ought to be... Of course, given my stated position on
> source maintenance of components, I wouldn't personally be concerned about
> recompiling them from source anyhow. The solution would be to wrap them as
> ActiveX or COM components then they COULD be exchanged. GUIs are not so

But that is the point, they could *not* be exchanged.  At leasts not
without paying runtime fees. The system would require both runtimes to work.

Donald



> different, it's just that you seem to be dealing with them at a much lower
> level than I would expect. Nothing wrong with that, but it is time
> consumiong and a lot of work. On the other hand, it does give you complete
> control and insight into exactly how a given control works. I'd still favo
ur
> a control library of components that oun can simply driop onto a form or
> desktop.
>
> Pete.
>
>
>

Pete Dashwood wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:zw6Pf.112723$H%4.20576@pd7tw2no...
> 
>
> I'm not so sure, but I wouldn't want to do it and I agree it would be more
> difficult than it ought to be... Of course, given my stated position on
> source maintenance of components, I wouldn't personally be concerned about
> recompiling them from source anyhow. The solution would be to wrap them as
> ActiveX or COM components then they COULD be exchanged. GUIs are not so
> different, it's just that you seem to be dealing with them at a much lower
> level than I would expect. Nothing wrong with that, but it is time
> consumiong and a lot of work. On the other hand, it does give you complete
> control and insight into exactly how a given control works. I'd still favo
ur
> a control library of components that oun can simply driop onto a form or
> desktop.
>
Components. Bloody evangelist :-)

I was relating it as a comparison to what Howard was referring to. You
could pass source for recompilation or give them a DLL - within a
particular mainframe family *perhaps*.

Cast your mind back - softwaresimple - you made some reference to pic
9(09) comp-5 in F/J. "Hmm, good idea", I thought for compatibility. I
can do a global search on a project in N/E so changed all my pic x(4)
comp-5 to yours when I found them. Recompiled - no big deal. Run the
application - DISASTER ! The N/E support classes are all pic x(4)
comp-5, so getting the results from them just wasn't kosher. Fortunately
re-searching I CHANGED them all back again ! That's just one aspect.

If we respectively took the DLL approach - even there it wouldn't work
smoothly would be my guess. And even with DLL you need the two runtimes
and supporting DLLs (from either F/J or M/F classes). It's just a bloody
mess.

Throw in Donald's reference to runtimes for good measure. Want to
communicate between two COBOLs - Java, C-languages, whatever, and yes
could use your component approach. The only satisfactory way being to
avoid COBOL as much a possible. Next Question - why use COBOL ?

Jimmy

Alistair wrote:
> James J. Gavan wrote:
> 
>
>
> Not true. If you have signed across your intellectual property rights
> then the product of your labour at your bosses' expense is his; if you
> have not signed away your rights then the property remains yours
> (certainly under UK law). I saw a software house fall foul of this when
> they let go of a contractor who had designed and built the company
> problem/change management system prior to making a major upgrade. Under
> UK law they were not permitted to make any change to the code or the
> system without his express written permission. It cost them a whole wad
> of cash to buy the rights to the system.
>
No wonder lawyers make a nice living Alistair.

Back when I was studying for Chartered Institute of Secretaries. Common
Law or Corporate Law - and I forget the descriptor - but if you are an
employee and decide to go off into business on your own you are
prohibited from sing his customers, carbon-copying his products or
services. (I think there was a time period).

Now whatever the specific rules are on the topic I'm referring to, what
you've stated seems diametrically opposed, as a point of law. "The Law
is an Ass".

Still another aspect of Law, and why my tutorials even covered it I have
no idea. There was a 'British Citizenship Act' about 1947. If you were
born in the Auld Sod - Ireland - prior to ....... 1920 (?????) then you
were AUTOMATICALLY a British citizen, without any paperwork. (Bearing in
mind births in Ireland were registered under British documentation, just
as for you and me).

So my dear old Dad, born in Dublin in 1901, left Ireland at about the
age of 14-16 with his family to settle in the Capital of Ireland -
Liverpool. Even joined the army in WWI - but too young to go before it
finished. So then in about 1970 wants to visit his second son, (not me),
here in Calgary. The bullshit he had to go through to prove he was a
Brit and get a UK passport. He would have had an easier time if he had
been in the KGB !

Jimmy

"Donald Tees" <donald_tees@sympatico.ca> wrote in message
news:SxePf.985$Qh1.21359@news20.bellglobal.com...
> Pete Dashwood wrote: 
> \> 
>
> But that is the point, they could *not* be exchanged.  At leasts not
> without paying runtime fees. The system would require both runtimes to
> work.
>
> Donald
>
Yes, absolutely. That is where the promise of dotNET comes in... A single
CLR... and, as far as I know, it is free. (Mind you, the download of the
framework is around 20MB...)

Pete

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:vAsPf.120481$sa3.83353@pd7tw1no...
> Pete Dashwood wrote: 
> Components. Bloody evangelist :-)
>
Well, I may be an evangelist, but you are preaching to the choir.... :-)

Pete.