Release of COBOL to Java Code Translator
AiZhong Li
It's my pleasure to announce that our COBOL to Java code translation product
Cobol2Java is released today.
Now you can convert your COBOL code into Java code in the easiest
way ---just hit one red button. In addition to both Java and COBOL features,
the readability of generated Java code for future maintenance is enhanced by
our translation strategy: comment to comment, line to line, file to file.
For what our product will bring to your COBOL applications, please visit our
company web site: www.corporola.com for details.
Thank you for your interests in our product.
Thomas Li
President of Corporola Inc.
Colin Campbell
Thomas A. Li
code even more than before.
If you got COBOL code, our product can make your COBOL code to run anywhere
by the follwoing approach:
prepare COBOL code (using your
current tools)
Translate into Java Code (using our
product)
Compile Java Code into Java classes (using free Java
compiler)
Run Java classesfrom COBOL anywhere (using free Java runtime)
Now you can modify either COBOL code or Java codeas you like. COBOL
is there and Java is one more option. But Java class, the binary Java code,
is the core for writing once and run anywhere. The same is true for C# from
Microsoft.
Thomas Li
Corporola Inc.
"Colin Campbell" <cmc...@attglobal.net> wrote in message
news:3E91D62C...@attglobal.net...
Danny Maijer
I never believed in Java kicking off Cobol from its throne....The J2EE
concept is GREAT (I mean this!) but suffers a lack of maturity (after all
(?) those years)...
I have been developing in Cobol for many years and have seen a lot of
projects being wrapped up successfully, both in time and budget. For Cobol
projects that is....
When Delphi arose, and PowerBuilder came along (you can think up more) I
have put my money on these horses in believe they would slam the old
architecture and would pay off in way less time (and budget) in regard to
the old Cobol IDE's...
What a disappointment however....Until now I never saw a Java (same goes for
the others) application meeting the time/quality standards achieved in Cobol
environments....(did I perform a Kamikaze act here ?).
Nowadays Cobol vendors offer a stable and well proven (!) environment for
developing SOLUTIONS instead of technical Walhalla's (catch the drift ?). I
think this goes for RM/MF/Fujitsu and the ones I dont know.....
I am talking from the point of view of a developer that needs to meet the
deadlines and quality assurance agreed upon with the customer.....As a
techie ? I love Java.....(but wont sell it (yet))
Regards, Danny (go ahead, shoot me...;)
"Thomas A. Li" <t...@corporola.com> schreef in bericht
news:Zslka.81901$pNv....@news02.bloor.is.net.cable.rogers.com...
JerryMouse
"AiZhong Li" <ali...@rogers.com> wrote in message
news:rOika.81013$pNv....@news02.bloor.is.net.cable.rogers.com...
There are 1,189 chapters, 31,102 verses, 783,137 words, and 3,566,480
letters in the King James Bible. It is estimated seventeen man-years were
expended in this interesting, but ultimately useless, endeavor.
JAVA will probably outlast Sun Microsystems, but COBOL will outlast the sun.
Robert Wagner
> Now you can modify either COBOL code or Java codeas you like. COBOL
>is there and Java is one more option. But Java class, the binary Java code,
>is the core for writing once and run anywhere. The same is true for C# from
>Microsoft.
There is an important difference. Your Java code is likely to be interpreted
whereas C# will ALWAYS be compiled by a JIT compiler. The speed difference will
be at least 6:1.
Granted, some JVM contain a compiler back-end. But many/most do not.
Thomas A. Li
C# before C# can run as many platforms as Java. I would prefer C# because
everything is object in C# and it makes reflection API easier to use.
I found Java and C# are almost the same thing after I checked their VM
instructions.
Thomas Li
"Robert Wagner" <rob...@wagner.net> wrote in message
news:3e926c7d....@news.optonline.net...
Thomas A. Li
man-years. If we rewrite it, it can be finished in one man-year. Most part
of the translator is automatically generated from its grammar definition.
The tools we developed for developing the translator really speeded up the
process a lot.
Thomas Li
"JerryMouse" <nos...@bisusa.com> wrote in message
news:-r2dnbiMqIR...@giganews.com...
Joe Zitzelberger
rob...@wagner.net (Robert Wagner) wrote:
What?!? I don't think ANY manufacturer, certainly not any large
manufacturer, is using a straight interpreter. Sun even roll the
Symantic "Hotspot" just in time engine into all the reference
implementations like 5 years ago.
That is complete FUD spread by Micro$oft, who rebundled their JIT/JVM
(formerly known as Visual J++ or somesuch) to interpret "MSIL" instead
of "Java bytecodes", but the instruction sets are remarkabily similar.
Bob Wolfe
>After we have finished the translator, we found it can be finished in 2
>man-years. If we rewrite it, it can be finished in one man-year. Most part
>of the translator is automatically generated from its grammar definition.
>The tools we developed for developing the translator really speeded up the
>process a lot.
>
>Thomas Li
Thomas:
I don't think that speed is the issue........
I think that one of the most important issues in any attempt to create
a language translation tool is the maintainability of the source code
which is created from the translator.
While it is certainly possible to translate source from language A to
language B.....if the result is translating very well-written COBOL
source code to poor quality (insert target language here), then the
effort is not only costly, but also pointless.
If you search the usenet archives, you will find dozens and dozens of
postings on COBOL to C translation tools, COBOL to Visual Basic
translation tools, etc.
...I really can't say how successful any of these tools were in the
marketplace, but I do know this.......
...there is still a massive amount of COBOL code and not a whole lot
of discussion on language translation any more.
I do wish you the best of luck, but perhaps speed of conversion is a
secondary matter to quality of the translated source code.
Bob Wolfe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When replying by e-mail, make sure that you correct the e-mail address.
Check out The Flexus COBOL Page at http://www.flexus.com
Thane Hubbell
I gotta laugh. Things are striking me funny of late.
I checked out your web site, and viewed the example there. So much
for COBOL being verbose! A very short simple COBOL program is double+
in Java.
Anyway - some serious questions. I know LegacyJ.com has PerCOBOL a
full COBOL environment for Java - that is really quite capable, and
has features from the 2002 standard. I was quite impressed with their
indexed file and sort implementations. Some questions about your
tool:
Does it support indexed files? Using what as a basis for the file
system?
Which COBOL vendor dialects are supported? Your spec sheet says COBOL
74 or COBOL 85, but what about specific and common vendor extensions?
Thanks for any information you can provide.
"Thomas A. Li" <t...@corporola.com> wrote in message news:<Zslka.81901$pNv....@news02.bloor.is.net.cable.rogers.com>...
Thomas A. Li
design. Comment to comment, line to line, file to file are the basis in
addition to a set of Java API to simulate COBOL data definition, which make
Java code reads like COBOL code.
Thomas A. Li
"Bob Wolfe" <rtw...@flexus.com> wrote in message
news:6lk59vsmnq4mml9q3...@4ax.com...
Paul Barnett
news:mECka.87392$pNv....@news02.bloor.is.net.cable.rogers.com...
> Readability for future maintenance is the first priority of our product
> design. Comment to comment, line to line, file to file are the basis in
> addition to a set of Java API to simulate COBOL data definition, which
make
> Java code reads like COBOL code.
>
> Thomas A. Li
>
Java - what I am against is people using the wrong tool for the job. Java
has its strengths and weaknesses, COBOL has its strengths and weaknesses.
Use each for the task it was intended - and for Business Rules - that's
COBOL.
Using Micro Focus tools - such as Net Express and Server Express, you can
keep your business rules whare they belong - in COBOL and interface to any
other technology you like to provide the rest of the infrastructure. With
the next major release - this will include Web Services - without the need
for J2EE or .NET.
Joe Zitzelberger
"Paul Barnett" <paul.b...@nospam.microfocus.com> wrote:
> Oh dear - why why why would anyone want to do this. I've nothing against
> Java - what I am against is people using the wrong tool for the job. Java
> has its strengths and weaknesses, COBOL has its strengths and weaknesses.
> Use each for the task it was intended - and for Business Rules - that's
> COBOL.
>
> Using Micro Focus tools - such as Net Express and Server Express, you can
> keep your business rules whare they belong - in COBOL and interface to any
> other technology you like to provide the rest of the infrastructure. With
> the next major release - this will include Web Services - without the need
> for J2EE or .NET.
>
> Paul
> www.microfocus.com
I can see a two great uses for it, both involve an intermediate compile
step only.
The first, in cases where no suitable Cobol compiler is available, like
Macintosh System, could run Cobol applications via an intermediate
Cobol2Java step.
The second, in cases where it becomes expensive to leave the bean
container to move over to another language, like calling Cobol from Java
on IBM mainframes. The performance hit could be completely elemenated
by converting the Cobol business rules into Java and keeping them all in
a single environment.
I can't imagine anyone wanting to keep or maintain the source generated
by these things...but that is just me...
Howard Brazee
On 9-Apr-2003, "Paul Barnett" <paul.b...@nospam.microfocus.com> wrote:
> Oh dear - why why why would anyone want to do this. I've nothing against
> Java - what I am against is people using the wrong tool for the job. Java
> has its strengths and weaknesses, COBOL has its strengths and weaknesses.
> Use each for the task it was intended - and for Business Rules - that's
> COBOL.
I suspect because a company doesn't want to hire CoBOL and Java programmers.
Maybe they do no new development in CoBOL, but have some old business programs.
Maybe they don't want to pay licensing fees to keep the CoBOL compiler.
There are a lot of tools that would be optimal - if we only knew how to use
them.
Ray Smith
> I suspect because a company doesn't want to hire CoBOL and Java programmers.
> Maybe they do no new development in CoBOL, but have some old business programs.
It's difficult to hire COBOL programmers now ... what will it be like in 10 or
20 years since "almost" no COBOL courses are run anymore??
And it's not just the fact that fewer and fewer people "know" COBOL, the
bigger challenge is that fewer and fewer people "want" to know COBOL.
Allot of developers believe COBOL is a dead-end job and have upgraded (or re-
skilled!!!) to different technologies.
Undergraduates don't want to start working in a COBOL shop because it isn't
"cool" and they are fearful of being left behind in a dead-end technology.
... so maybe a COBOL to Java translator might be useful for different "non
technical" reasons??
Note: I don't agree that COBOL is a dead-end technology but if you ask the
average person on the street (or in IT :) ) most would say
"COBOL? ... yes COBOL I used to know COBOL ... do people still use that?".
Regards,
Ray Smith
r...@rays-web.com
Peter E.C. Dashwood
It will make uninformed Managers think they have done something significant
to convert the Company's COBOL code into a "modern" language but, in fact,
all they have done is degrade Java.
Unless the innate OO nature of Java is preserved (and I don't see how it can
be if you are doing a computer based "translation" of NON -OO COBOL code),
all you will end up with is Java code that is more cumbersome than the COBOL
you started out with.
If you are converting OO COBOL to Java, you might have a point, but if the
COBOL code is OO there would be no need to convert it to another OO
language, right?
Just exactly what advantage do you expect to achieve by this decidedly
suspect operation?
Pete.
"Thomas A. Li" <t...@corporola.com> wrote in message
news:Yszka.61632$az1....@news01.bloor.is.net.cable.rogers.com...
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
James J. Gavan
"Peter E.C. Dashwood" wrote:
> Converting standard non-OO COBOL to Java is a pointless waste of time.
>
> It will make uninformed Managers think they have done something significant
> to convert the Company's COBOL code into a "modern" language but, in fact,
> all they have done is degrade Java.
>
> Unless the innate OO nature of Java is preserved (and I don't see how it can
> be if you are doing a computer based "translation" of NON -OO COBOL code),
> all you will end up with is Java code that is more cumbersome than the COBOL
> you started out with.
>
> If you are converting OO COBOL to Java, you might have a point, but if the
> COBOL code is OO there would be no need to convert it to another OO
> language, right?
>
> Just exactly what advantage do you expect to achieve by this decidedly
> suspect operation?
>
> Pete.
>
Couldn't agree more. Like it not it requires you to 'change hats' when you move from
non-OO to OO. If you want a really Mickey Mouse approach just take non-OO COBOL and
turn each PERFORM PARAGRAPH into a separate method - looks good and would work, but
doesn't do a damn thing for you. I wonder what happens when you use an SQL
Preprocessor ?
I betcha it will hiccup if you were to try and convert an OO COBOL class into Java OO
!
Let me re-emphasize with regard to IBM Enterprise - Mike Murtach's examples would work
with IBM, (subject to any restrictions there might be about mainframe File Handling -
where the O/S support is used in lieu of COBOL syntax). Java utilities only come into
play when you want other than bread and butter COBOL classes for Business logic
handling, and of course 'windowing' (GUIs).
PS: Mike Murtach's examples compile cleanly - but don't work ! None of his invoked
classes has a FACTORY method with method-id "new". Did write and query - but to date
no reply.
Jimmy, Calgary AB
Howard Brazee
On 9-Apr-2003, r...@rays-web.com (Ray Smith) wrote:
> It's difficult to hire COBOL programmers now ... what will it be like in 10 or
> 20 years since "almost" no COBOL courses are run anymore??
When I started, most CoBOL programmers were trained by their employers. Is
company training dead now?
Thomas A. Li
One of in-laws has got more than 20 years experience as a mainframe
administrator, but he was laid off last year, 3 years before his retirement.
Now he teaches high school math.Why?
Thomas Li
"Howard Brazee" <how...@brazee.net> wrote in message
news:b73t36$7iq$1...@peabody.colorado.edu...
Bob Wolfe
>In article <b71021$flh$1...@hyperion.microfocus.com>,
> "Paul Barnett" <paul.b...@nospam.microfocus.com> wrote:
>
>> Oh dear - why why why would anyone want to do this. I've nothing against
>> Java - what I am against is people using the wrong tool for the job. Java
>> has its strengths and weaknesses, COBOL has its strengths and weaknesses.
>> Use each for the task it was intended - and for Business Rules - that's
>> COBOL.
>>
>> Using Micro Focus tools - such as Net Express and Server Express, you can
>> keep your business rules whare they belong - in COBOL and interface to any
>> other technology you like to provide the rest of the infrastructure. With
>> the next major release - this will include Web Services - without the need
>> for J2EE or .NET.
>>
>> Paul
>> www.microfocus.com
>
>I can see a two great uses for it, both involve an intermediate compile
>step only.
>
>The first, in cases where no suitable Cobol compiler is available, like
>Macintosh System, could run Cobol applications via an intermediate
>Cobol2Java step.
Joe:
Several of our customers run Virtual PC on the Mac and have
experienced great success.
They run stand-alone Windows applications as well as utilizing the Mac
as a client machine in a Thin Client/Server environment.
Most run client/server with a UNIX server and a Mac client. Great
combination.......no Java necessary.
>The second, in cases where it becomes expensive to leave the bean
>container to move over to another language, like calling Cobol from Java
>on IBM mainframes. The performance hit could be completely elemenated
>by converting the Cobol business rules into Java and keeping them all in
>a single environment.
>
>I can't imagine anyone wanting to keep or maintain the source generated
>by these things...but that is just me...
Thane Hubbell
apparently missed them becaues you didn't answer. Here they are
again:
Hello Thomas,
I gotta laugh. Things are striking me funny of late.
I checked out your web site, and viewed the example there. So much
for COBOL being verbose! A very short simple COBOL program is double+
in Java.
Anyway - some serious questions. I know LegacyJ.com has PerCOBOL a
full COBOL environment for Java - that is really quite capable, and
has features from the 2002 standard. I was quite impressed with their
indexed file and sort implementations. Some questions about your
tool:
Does it support indexed files? Using what as a basis for the file
system?
Which COBOL vendor dialects are supported? Your spec sheet says COBOL
74 or COBOL 85, but what about specific and common vendor extensions?
Thanks for any information you can provide.
"Thomas A. Li" <t...@corporola.com> wrote in message news:<R9fla.182$CV...@news04.bloor.is.net.cable.rogers.com>...
Thomas A. Li
I know LegacyJ. But LegacyJ translate COBO Linto Java binary while we just
want to reuse source code for further maintenance.
>> Does it support indexed files? Using what as a basis for the file
system?
Yes. Based on random access file.
>> Which COBOL vendor dialects are supported? Your spec sheet says COBOL
74 or COBOL 85, but what about specific and common vendor extensions?
We support Micorfocus. But for unsupport or not support stuff, we give
error, warnings or info for manual editing.
For example, we don't want to support perform statement with a through
clause. I don't think it is a good structure and it can be avoided.
We're now upgrading our website and writing manuals. After a month,
everything will be in its place.
Thanks for your questions.
Thomas Li
"Thane Hubbell" <tha...@softwaresimple.com> wrote in message
news:bfdfc3e8.03041...@posting.google.com...
Joe Zitzelberger
Bob Wolfe <rtw...@flexus.com> wrote:
> >
> >The first, in cases where no suitable Cobol compiler is available, like
> >Macintosh System, could run Cobol applications via an intermediate
> >Cobol2Java step.
>
> Joe:
>
> Several of our customers run Virtual PC on the Mac and have
> experienced great success.
Sometimes useful, but often slow, tedious and does not fix the core
problem -- having to use Windoze. But Mac was just one example, there
are plenty of smallish OSen available. Outside of Solaris, Linux, Win32
how many do you support?
> They run stand-alone Windows applications as well as utilizing the Mac
> as a client machine in a Thin Client/Server environment.
There, you used the W-word again ;-)
Joe Zitzelberger
"Howard Brazee" <how...@brazee.net> wrote:
Hmmm, I wouldn't bet on company training at all. Wasn't there a recent
parallel thread (or was it a threat?) suggesting someone make a business
case for encapsulation?
Now try to explain to a non-programing manager why it is important to
teach the new hires about encapsulation.
If they don't know how to program before they hit the company, I doubt
they will ever learn without lots of personal initiative...
JerryMouse
"Joe Zitzelberger" <joe_zitz...@nospam.com>
> >
> > Several of our customers run Virtual PC on the Mac and have
> > experienced great success.
>
> Sometimes useful, but often slow, tedious and does not fix the core
> problem -- having to use Windoze. But Mac was just one example, there
> are plenty of smallish OSen available. Outside of Solaris, Linux, Win32
> how many do you support?
"Windoze?"
Imagine the world of computer users could be represented by a battalion of
100. As they march by, we note:
90 are Windows users.
5 are Apple users.
3 are mainframe and mini users.
2 are something else.
One sitting in the reviewing stand is heard to whisper in his neighbor's
ear: "Looks like 90 of them are out-of-step!"
Fey!
"Windows and Hong Kong - they take your breath away!"
Thomas A. Li
So far, I can't find a wide-used platform without Java. If any, please tell
me.
Thomas Li
Richard Plinston
> 90 are Windows users.
> 5 are Apple users.
> 3 are mainframe and mini users.
> 2 are something else.
You've been listening too much to MS propaganda. The above depends
entirely on what is defined as being a 'computer user'. If it is
restricted to _only_ being those computers which sit on or under a person's
desk and have a monitor and keyboard and are for use by that person then
the figures are about right - give or take a few percent.
What _isn't_ indicated is that those computers are also used to access
other systems. Often a Windows PC is installed just to be used as a dumb
terminal and the systems are actually mainframe or Unix applications.
While the above is contrived to add up to 100%, a more realistic 'user'
count would come out at 150% or more to include the fact that a user 'uses'
more than one machine. Even when Windows applications are run the data is
held on a server which is more likely to be a mainframe or Unix system than
a Windows one.
When you post to this group you become a user of this system (google) -
where Unix/Linux rules.
Joe Zitzelberger
"JerryMouse" <nos...@bisusa.com> wrote:
Actually, I'm all of the above.
But I think this is one of those cases of 'Lies, damn lies, and
statistics'. Whenever I see these numbers it is usually number of
computers sold in a given year or number of OS licenses sold in a given
year.
While I will not argue that a great majority are indeed Windoze
boxes/licenses/users, your figures are inherently skewed. Some
interesting things to consider:
- Micro$oft forces users to "renew" perfectly good licenses every
year or two by repackaging the same OS under a different name and
charging again. (Win3, Win3.1, Win3.11) (Win95, Win95B, Win98, WinME)
(WinNT3.5, WinNT4, WinNT, Win2k). In that same time Apple sold three OS
varients -- System 7, System 8 and System 9, you always got the latest
version with a hardware purchase plus free upgrades released anywhere in
the comming 90 days to 1 year.
Thus, through the 90's, I bought 3 Macs and 3 licenses. But I also
bought 18 intel boxes for use with Linux (16), Be (1) and Solaris7 (1)
and got a Micro$oft license for each. Did that count as high-80s for
M$? single digits for apple and zilch for something else?
- Windows is predominant in places where there tends to be a 1-to-1
or less computer ratio (the corporate world). Macs tend to the
many-to-1 places (school classrooms, computer labs). I've seen TCO
studies in the past that indicate the average mac has more users than
the average windows box and a longer life time. How have your numbers
controlled for that.
- Yearly hardware purchase numbers are skewed by tax depreciation
laws that inspire corporations to write-off and destroy systems after a
few years, forcing repurchase of new hardware. Schools and homes do not
have such cut-offs and tend to extend the life of their systems
accordingly.
- While only 5 (or 10, or 13, or 3) percent are Apple users, Apples
are predominantly targeted at the home. I've seen numbers ranging from
25 to 40 percent of homes. Does that make a family of 5 into 5 Apple
users or 1 Apple machine?
- If our mythical family of 5 has two 'information age' workers, each
with a Windoze box in their cube used to connect to a mainframe does our
statistical world now look 66% windows, 33% apple and only the MVS
operator in the basement counts for the mainframe?
- If Dell/Gateway/whoever sells me a system with some strain of
Windoze installed and I immediatly apply partition magic and install one
of the Linuxen varients -- how do you know I became one of the 2%
something else? Who keeps track? Do I still count as one of the 90%
just because I had to buy a M$ license?
>
> One sitting in the reviewing stand is heard to whisper in his neighbor's
> ear: "Looks like 90 of them are out-of-step!"
>
You may indeed say that. But it will be the case that the 90 are
straggling behind unsure where to step.
When the 90 were:
- over a decade behind in getting peer-to-peer networking
- over a decade behind in getting OS managed printing
- six+ years behind in getting 32-bit code (is all the 16-bit gone???
XP maybe...)
- a decade behind in getting a TCP/IP stack in the OS
- fifteen years behind in getting a usable, self-powered,
daisy-chainable serial bus
- a decade behind in getting an integrated, scriptable environment
- fifteen years behind in having an OS that would support reasonable
fixed disk sizes
- six or seven years behind in spoken commands
- a decade behind in decent audio support
- a decade behind in decent video support
- two decades behind in multiple monitor support
- six or seven years behind in a personalized user experience
(desktop settings, preferences, etc) for each user without a server
- six or seven years behind in any kind of security without a server
- fifteen years behind in getting _functional_ plug-and-play support
of devices
- still unable to capture the finer points of a decent user interface
...the list goes on...
I'll stick with the 10 that were in front showing them the way.
For the record, I use Windoze far more than I do a Mac. I've worked,
daily, with every M$ operating system since DOS3.2 with the exceptions
of 98, ME and XP (though I've used 98, XP plenty, just not daily, more
NT2KAS).
It isn't as if I don't know what Windoze is like, it is that I know
there is something far superior available.
Now, if I have a win desktop at work, a win server in the attic
gathering dust, signons to 20 different mainframes and a Mac with two
virtual Win machines and a virtual mainframe running on my desk as I
type this, which group do I fall into?
Bob Wolfe
>In article <1jcb9vseh0qdo4mjh...@4ax.com>,
> Bob Wolfe <rtw...@flexus.com> wrote:
>> >
>> >The first, in cases where no suitable Cobol compiler is available, like
>> >Macintosh System, could run Cobol applications via an intermediate
>> >Cobol2Java step.
>>
>> Joe:
>>
>> Several of our customers run Virtual PC on the Mac and have
>> experienced great success.
>
>Sometimes useful, but often slow, tedious and does not fix the core
>problem -- having to use Windoze. But Mac was just one example, there
>are plenty of smallish OSen available. Outside of Solaris, Linux, Win32
>how many do you support?
I'm not sure what you mean by "OSen" Emulators?
Our server software supports:
All UNIX and UNIX derivative platforms, including Solaris, Linux, AIX,
HP-UX, etc.
All 32 bit Windows server environments
VAX/VMS
OpenVMS
UNIX System Services on S/390 environments
Client side environments supported are 32 bit Windows clients.
We could develop a native Mac client or native Gnome or KDE client for
the Linux desktop, but practicality prevents us from doing so. The
problem isn't technical, it's ROI. Because these client environments
represent a small percentage of the target client environments for
business applications, we wouldn't be able to achieve a reasonable ROI
in a timely fashion.
Non-Windows server environments....now that's a different matter.
These environments are in much wider use than non-Windows client
machines. They are a heck of a lot more powerful and reliable as
well.
>> They run stand-alone Windows applications as well as utilizing the Mac
>> as a client machine in a Thin Client/Server environment.
>
>There, you used the W-word again ;-)
Peter E.C. Dashwood
"Joe Zitzelberger" <joe_zitz...@nospam.com> wrote in message
news:joe_zitzelberger-12...@corp.supernews.com...
Peter E.C. Dashwood
Icon then accidentally activating it...<G>)
I was interested to see the the list of facilities which MS were "late" in
implementing.
I've also worked with MS software since the early releases of DOS and I take
no issue with your list.
BUT the fact is that NOW they DO have everything you mentioned. And the PC
platform has more software availabe for it than ANY other computer platform.
I can't see any point in arguing for or against platforms as I don't believe
any minds will be changed.
All I will say is that I moved to XP Professional just after Xmas last year.
I was going to replace it with Win 2000, as I heard it was crap. Instead, I
have stayed with it and I wouldn't swap it now for any other PC OS I have
used. It has NEVER crashed, frozen or failed. When MS applications abend
(like Outlook does every so often...) it sends a report to MS and restarts
from where it was, restoring my in-progress mail from the drafts folder. I
have MS currently looking at the problem and the support has been excellent.
(There has been no charge as I am a registered user of the software.)
I have never been happier with my PC than I am at the moment. XP Pro is a
significant forward step in MS evolution. I'm running it on a Pentium 4
laptop (2.5 GHz) with 256 MB of real memory. It behaves.
Pete.
"Joe Zitzelberger" <joe_zitz...@nospam.com> wrote in message
news:joe_zitzelberger-12...@corp.supernews.com...
JerryMouse
But I think this is one of those cases of 'Lies, damn lies, and
statistics'. Whenever I see these numbers it is usually number of
computers sold in a given year or number of OS licenses sold in a given
year.
---
Agreed. My figures were 'made up,' not based on fact but on impressions of
the marketplace from my little corner.
---
While I will not argue that a great majority are indeed Windoze
boxes/licenses/users, your figures are inherently skewed. Some
interesting things to consider:
- Micro$oft forces users to "renew" perfectly good licenses every
year or two by repackaging the same OS under a different name and
charging again. (Win3, Win3.1, Win3.11) (Win95, Win95B, Win98, WinME)
(WinNT3.5, WinNT4, WinNT, Win2k). In that same time Apple sold three OS
varients -- System 7, System 8 and System 9, you always got the latest
version with a hardware purchase plus free upgrades released anywhere in
the comming 90 days to 1 year.
---
I've never been 'forced' although I've bought and used all of those on your
list. I always thought the features were worth the price.
Apple's failure to provide a proper business model should not be hailed as
beneficial.
Updates to all of Micros~1's products are free. Upgrades during the same
time interval as you mentioned are also free. By that, I mean I've seen
promotions like "Buy now (with Win95 installed) and get a free upgrade to
Win98 next month (when released)."
---
Thus, through the 90's, I bought 3 Macs and 3 licenses. But I also
bought 18 intel boxes for use with Linux (16), Be (1) and Solaris7 (1)
and got a Micro$oft license for each. Did that count as high-80s for
M$? single digits for apple and zilch for something else?
---
Strange - I've bought even more computers in the last 13 years and only two
came with an OS installed (laptops). 'Course I usually buy the parts and put
'em together myself.
---
- Windows is predominant in places where there tends to be a 1-to-1
or less computer ratio (the corporate world). Macs tend to the
many-to-1 places (school classrooms, computer labs). I've seen TCO
studies in the past that indicate the average mac has more users than
the average windows box and a longer life time. How have your numbers
controlled for that.
---
That's probably true. No I haven't controlled for that - as I said, my
numbers are fictious.
---
- Yearly hardware purchase numbers are skewed by tax depreciation
laws that inspire corporations to write-off and destroy systems after a
few years, forcing repurchase of new hardware. Schools and homes do not
have such cut-offs and tend to extend the life of their systems
accordingly.
---
Huh? No corporation "destroys" productive, functioning equipment. The
equipment may have a book/depreciated value of zero, but there's no mandate
to junk it.
---
- While only 5 (or 10, or 13, or 3) percent are Apple users, Apples
are predominantly targeted at the home. I've seen numbers ranging from
25 to 40 percent of homes. Does that make a family of 5 into 5 Apple
users or 1 Apple machine?
---
I dunno.
---
- If our mythical family of 5 has two 'information age' workers, each
with a Windoze box in their cube used to connect to a mainframe does our
statistical world now look 66% windows, 33% apple and only the MVS
operator in the basement counts for the mainframe?
---
6 Windows boxes, 3 Apple boxes, and 1 MVS mainframe = 60% Windows boxes. If
based on teraflops or cost, the percentage would differ.
---
- If Dell/Gateway/whoever sells me a system with some strain of
Windoze installed and I immediatly apply partition magic and install one
of the Linuxen varients -- how do you know I became one of the 2%
something else? Who keeps track? Do I still count as one of the 90%
just because I had to buy a M$ license?
---
In the marching battalion metaphor, you count as a camp-follower.
---
>
> One sitting in the reviewing stand is heard to whisper in his neighbor's
> ear: "Looks like 90 of them are out-of-step!"
>
You may indeed say that. But it will be the case that the 90 are
straggling behind unsure where to step.
When the 90 were:
[snip list of Window's deficiences]
I'll stick with the 10 that were in front showing them the way.
---
You can lead, but the question is how many follow? Remember Esperanto? How
about the group that wants to decimalize the hours in the day and the
calendar? Metrification of speed-limit signs in the U.S.? Hale-Bopp? The
Reform Party? Electric cars?
No, simply because something is better doesn't make it better (which reminds
one of Marilyn Monroe's famous answer to the question of whether she wore
falsies: "People who know me better, know me better").
---
It isn't as if I don't know what Windoze is like, it is that I know
there is something far superior available.
---
I feel the same way about my wife, but that doesn't mean...
---
Now, if I have a win desktop at work, a win server in the attic
gathering dust, signons to 20 different mainframes and a Mac with two
virtual Win machines and a virtual mainframe running on my desk as I
type this, which group do I fall into?
---
Neurotic?
---
Joe Zitzelberger
> (Oops, sorry about previous post...caused by leaving the mouse on the "Send"
> Icon then accidentally activating it...<G>)
>
> I was interested to see the the list of facilities which MS were "late" in
> implementing.
>
> I've also worked with MS software since the early releases of DOS and I take
> no issue with your list.
>
> BUT the fact is that NOW they DO have everything you mentioned. And the PC
> platform has more software availabe for it than ANY other computer platform.
True, but how many web browser choices do you need? FTP clients?
Word Processors? In all cases I have multiple choices, just slightly
different from the win versions. Outside of the gaming world (Panzer
General III), and Cobol compilers, I've never seen a win program that
I couldn't find a mac analog for.
> I can't see any point in arguing for or against platforms as I don't believe
> any minds will be changed.
True, very true.
> All I will say is that I moved to XP Professional just after Xmas last year.
> I was going to replace it with Win 2000, as I heard it was crap. Instead, I
> have stayed with it and I wouldn't swap it now for any other PC OS I have
> used. It has NEVER crashed, frozen or failed. When MS applications abend
> (like Outlook does every so often...) it sends a report to MS and restarts
> from where it was, restoring my in-progress mail from the drafts folder. I
> have MS currently looking at the problem and the support has been excellent.
> (There has been no charge as I am a registered user of the software.)
>
> I have never been happier with my PC than I am at the moment. XP Pro is a
> significant forward step in MS evolution. I'm running it on a Pentium 4
> laptop (2.5 GHz) with 256 MB of real memory. It behaves.
I think M$ finally got it right with Win2000 and XP -- they both seem
to be stable, easy to set up and have most of the memory leaks fixed.
They seem to be quite usable now, in fact I really like Win2k.
Peter E.C. Dashwood
Great post JerryMouse, really enjoyed it...
Pete.
"JerryMouse" <nos...@bisusa.com> wrote in message
news:NwKdnUbePtA...@giganews.com...
LX-i
> I have never been happier with my PC than I am at the moment. XP Pro is a
> significant forward step in MS evolution. I'm running it on a Pentium 4
> laptop (2.5 GHz) with 256 MB of real memory. It behaves.
Hear hear - I did a clean install of XP Pro on my laptop, and have had
no complaints out of it at all. (Of course, my COBOL compiler is on the
mainframe, so that part's not subject to XP...) XP Pro is much, much,
much more stable than W2K, and W2K was a big leap forward from NT 4...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / Live from Montgomery, AL! ~
~ / \/ o ~
~ / /\ - | AIM: LXi0007 ~
~ _____ / \ | E-mail: Dani...@Knology.net ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Michael Wojcik
Indeed. Competent programmers familiar with any medium-level procedural
programming language should have no difficulty learning COBOL, and
companies that need COBOL programmers should be able to find people to
hire and train. COBOL has a complicated grammar with a fair number of
gotchas, but then so does C.
I had a little COBOL in high school (which now that I think about it was
probably a relatively rare experience, even among COBOL programmers),
using a compiler that ran on TRS-80s (now you can play "guess Michael's
age"), a text called _Structured COBOL_ (heh), and a pad of HIPO charts.
I had the opportunity to take COBOL in college (Northeastern), but
took Fortran instead as I hadn't done any before. I wrote a couple of
small COBOL programs - mostly samples to ship with a middleware package
- before I started working for Micro Focus, but it was really here where
I learned COBOL in any significant way. And I just picked it up from
looking at code and documentation. (The vast majority of my work is in
C, so there wasn't any need to gain comprehensive COBOL knowledge quickly.)
As long as there's economic incentive to work with COBOL - which I
expect will be a long time - companies will find ways to get COBOL
programmers.
--
Michael Wojcik
Micro Focus International
Joe Zitzelberger
Bob Wolfe <rtw...@flexus.com> wrote:
> I'm not sure what you mean by "OSen" Emulators?
>
> Our server software supports:
> All UNIX and UNIX derivative platforms, including Solaris, Linux, AIX,
> HP-UX, etc.
> All 32 bit Windows server environments
> VAX/VMS
> OpenVMS
> UNIX System Services on S/390 environments
BSD?
>
> Client side environments supported are 32 bit Windows clients.
I assume you me 'development environment' by 'client side'?
Joe Zitzelberger
"JerryMouse" <nos...@bisusa.com> wrote:
> ---
> I've never been 'forced' although I've bought and used all of those on your
> list. I always thought the features were worth the price.
>
> Apple's failure to provide a proper business model should not be hailed as
> beneficial.
>
> Updates to all of Micros~1's products are free. Upgrades during the same
> time interval as you mentioned are also free. By that, I mean I've seen
> promotions like "Buy now (with Win95 installed) and get a free upgrade to
> Win98 next month (when released)."
Before 1996 Micro$oft had a deal with all the big name retailers -- if
they wanted to sell any Micro$oft product, they had to sell a Micro$oft
OS with every computer system.
This was very significent, because you might want an OS/2 box, and the
company might well sell you a shrinkwraped OS/2, even install it, but
you also got, and paid for, your Windows license.
M$ finally stopped doing this after DOJ got after them about it. But
not before I had plenty of "certs of auth" that I never needed or wanted
-- a few years ago I handed them out to kids trick or treating on
halloween.
> ---
> Strange - I've bought even more computers in the last 13 years and only two
> came with an OS installed (laptops). 'Course I usually buy the parts and put
> 'em together myself.
> ---
To make a long story even longer, there was once a mini-rebellion amonst
the laptop Linux community. I seem to recall it was based around
Toshibas. They want to not agree to the EULA when the computer boots up
and makes you click OK -- Micro$oft started out by claiming that they
had booted the computers, thus used the OS and did not deserve a refund,
then after much headache and hand-wringing they said that Toshiba ought
to provide the refund, I lost track of it somewhere around there, but I
don't think anyone has ever collected their refunds for the unused
Micro$oft products.
> ---
> Huh? No corporation "destroys" productive, functioning equipment. The
> equipment may have a book/depreciated value of zero, but there's no mandate
> to junk it.
> ---
There is a mandate to REPLACE it, so you can start depreciating the new
stuff. And, while it might not be common practice, my shop ditches the
older ones.
> ---
> In the marching battalion metaphor, you count as a camp-follower.
> ---
Ouch!
Well, there are few things I won't do for money...
> ---
> You can lead, but the question is how many follow? Remember Esperanto? How
> about the group that wants to decimalize the hours in the day and the
> calendar? Metrification of speed-limit signs in the U.S.? Hale-Bopp? The
> Reform Party? Electric cars?
>
> No, simply because something is better doesn't make it better (which reminds
> one of Marilyn Monroe's famous answer to the question of whether she wore
> falsies: "People who know me better, know me better").
> ---
That would be true if Windows were going in another direction. But it
isn't. That list was all the things that Mac users had that someone at
Redmond though -- 'hey, thats neat, why don't we inovate that into our
next product'.
As a friend used to quip -- "If you want to know where Windows will be
in 10 years, look at a Mac".
>> It isn't as if I don't know what Windoze is like, it is that I know
>> there is something far superior available.
> ---
> I feel the same way about my wife, but that doesn't mean...
Good Point. I'm quite happy with Wife v1.0, there is no reason to
upgrade.
> Now, if I have a win desktop at work, a win server in the attic
> gathering dust, signons to 20 different mainframes and a Mac with two
> virtual Win machines and a virtual mainframe running on my desk as I
> type this, which group do I fall into?
>
> ---
> Neurotic?
> ---
True, very true. And a sleep disorder as well.
docd...@panix.com
Joe Zitzelberger <joe_zitz...@nospam.com> wrote:
>In article <NwKdnUbePtA...@giganews.com>,
> "JerryMouse" <nos...@bisusa.com> wrote:
[snip]
>> Now, if I have a win desktop at work, a win server in the attic
>> gathering dust, signons to 20 different mainframes and a Mac with two
>> virtual Win machines and a virtual mainframe running on my desk as I
>> type this, which group do I fall into?
>>
>> ---
>> Neurotic?
>> ---
>
>True, very true. And a sleep disorder as well.
They are not all that uncommon... at times I, myself, suffer from
insomnia...
... but I try not to lose too much sleep over it.
DD
Bob Wolfe
Not necessarily. Server side with our Thin Client/COBOL sp2 product
refers to the machine on which the program executes.
Client side refers to the machine on which the user interface screens
are displayed.
The client side *could* also serve as a development machine, but it's
not a requirement.
Howard Brazee
On 12-Apr-2003, Michael Wojcik <mwo...@newsguy.com> wrote:
> I had a little COBOL in high school (which now that I think about it was
> probably a relatively rare experience, even among COBOL programmers),
> using a compiler that ran on TRS-80s (now you can play "guess Michael's
> age"), a text called _Structured COBOL_ (heh),
Obviously you're a kid. (for various values of us observers).
Michael Wojcik
To cross threads a bit and provide another data point: I've been
programming professionally (as a full-time employee hired specifically
to write code) for 15 years. No doubt that puts me on the young side of
the c.l.c average, but I noticed at least one regular poster cited a
career length less than half that.
Peter E.C. Dashwood
I agree with you that translating well written COBOL to ANY other language
is not productive.
What it comes down to is whether you intend to maintain the code.
If you do, then it makes sense to leave it in COBOL.
The Management argument will be: "But we can't get COBOL programmers as they
are a dying breed and the whole business of using COBOL is fraught with long
delays over standards, and arguments about the value of various features in
the language. We can get <language-du-jour> programmers because they are
cheap and plentiful." (Or, in some cases they will use cheap COBOL labour
sourced from the sub-continent...).
The point is that if you intend to maintain source code, then COBOL is
arguably the best language around for doing it.
But the REAL requirement is NOT to maintain source code. It is to implement
the business functions you require in as efficient a manner as possible.
ONE solution to that is decomposition of the legacy code and re-engineering
into components that can be re-used, deployed anywhere on any platform, and
possibly, sold for profit. (see my article at:
www.aboutlegacycoding.com/Articles/V/V50101.asp)
In today's environment it is short-sighted and stupid to try and run a shop
that is based around the "one language wonder" where we try and do
EVERYTHING in one language so it can be easily maintained. What we SHOULD be
doing is looking to NOT maintain it... (And more and more businesses are
actually doing this...the argument runs thus~: "We are an Insurance (or
whatever) Company. Why should we spend millions to maintain an IT facility
on a yearly basis, with costs that simply escalate, questionable quality of
service delivery, and being held to ransom by a bunch of technocrats? We
could outsource our requirements for a fraction of the cost...) This is why
we we are seeing an explosion in the use of "packaged solutions" like SAP,
Siebel, etc. They promise to deliver a solution and by the time it is found
out that they can't, it is too late...<G>. In some cases, of course, they
can, but either way, it is no longer the problem of the Insurance company...
The FACT is that we NEED different languages for different purposes (the
"best tools for the job").
Ultimately, what we need is functionality. The technicalities of how we
obtain it are largely irrelevant to the people who use it.
That is why I believe that ALL procedural languages will have a limited
remaining lifespan.(The future is Object Oriented...<G>)
And translating COBOL into another procedural language is pointless.
Pete.
"Bob Wolfe" <rtw...@flexus.com> wrote in message
news:6lk59vsmnq4mml9q3...@4ax.com...
> "Thomas A. Li" <t...@corporola.com> wrote:
>
> >After we have finished the translator, we found it can be finished in 2
> >man-years. If we rewrite it, it can be finished in one man-year. Most
part
> >of the translator is automatically generated from its grammar definition.
> >The tools we developed for developing the translator really speeded up
the
> >process a lot.
> >
> >Thomas Li
>
> Thomas:
>
> I don't think that speed is the issue........
>
> I think that one of the most important issues in any attempt to create
> a language translation tool is the maintainability of the source code
> which is created from the translator.
>
> While it is certainly possible to translate source from language A to
> language B.....if the result is translating very well-written COBOL
> source code to poor quality (insert target language here), then the
> effort is not only costly, but also pointless.
>
> If you search the usenet archives, you will find dozens and dozens of
> postings on COBOL to C translation tools, COBOL to Visual Basic
> translation tools, etc.
>
> ...I really can't say how successful any of these tools were in the
> marketplace, but I do know this.......
>
> ...there is still a massive amount of COBOL code and not a whole lot
> of discussion on language translation any more.
>
> I do wish you the best of luck, but perhaps speed of conversion is a
> secondary matter to quality of the translated source code.
>
>
>
> Bob Wolfe
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> When replying by e-mail, make sure that you correct the e-mail address.
> Check out The Flexus COBOL Page at http://www.flexus.com
>
LX-i
> to write code) for 15 years. No doubt that puts me on the young side of
> the c.l.c average, but I noticed at least one regular poster cited a
> career length less than half that.
Darnit... I knew that survey was just a ploy to get us all to know each
other a little better.... ;)
Joe Zitzelberger
<dash...@enternet.co.nz> wrote:
> This post made me think, Bob.
>
> I agree with you that translating well written COBOL to ANY other language
> is not productive.
>
> What it comes down to is whether you intend to maintain the code.
>
> If you do, then it makes sense to leave it in COBOL.
I can think of one specific case where it makes great sense to translate
the code into Java.
Some Cobol folks at IBM have commented that while their JVMs are good
and their Java fast there is a significent performance price for
crossing the JVM barrier to call out to a non-JVM program. It is easy
and transparent, but you don't want to do it constintly.
So if you find yourself with an architecture built around EJBs, but you
want your business rules in Cobol, it might be worthwhile to convert the
Cobol to Java and generate business rules that can stay within the JVM
space.
This gives the best of both worlds -- you can keep your Cobol source,
but you can also seemlessly play in WS and other containers, or run just
about anywhere. Its a win-win.
Stephen Gennard
you have to move your COBOL into Java when you can use the J2EE
Connector architecture to access COBOL.
All you need is a COBOL resource adapter...... which I am sure some
vendor may provide sooner rather than later.
If you want some background reading on the connector architecture check
out...
http://java.sun.com/j2ee/connector/
--
Stephen
Peter E.C. Dashwood
> In article <3ea5c...@127.0.0.1>, "Peter E.C. Dashwood"
> <dash...@enternet.co.nz> wrote:
>
> > This post made me think, Bob.
> >
> > I agree with you that translating well written COBOL to ANY other
language
> > is not productive.
> >
> > What it comes down to is whether you intend to maintain the code.
> >
> > If you do, then it makes sense to leave it in COBOL.
>
> I can think of one specific case where it makes great sense to translate
> the code into Java.
>
> Some Cobol folks at IBM have commented that while their JVMs are good
> and their Java fast there is a significent performance price for
> crossing the JVM barrier to call out to a non-JVM program. It is easy
> and transparent, but you don't want to do it constintly.
>
Performance is not a reason for converting. Beef up the hardware. (It is
getting cheaper all the time...)
> So if you find yourself with an architecture built around EJBs, but you
> want your business rules in Cobol, it might be worthwhile to convert the
> Cobol to Java and generate business rules that can stay within the JVM
> space.
>
Yes, I agree with that. But you would not then maintain the Business rules
in COBOL. (Why would you want to maintain TWO sets of Business Rules?)
You COULD use a tool like perCOBOL to generate the Java from your COBOL
(purely for the sake of performance and maintaining a single environment, if
you are REALLY persuaded that this is important) but, as long as you try to
maintain COBOL code as well as the EJBs, you have an unwieldy solution. It
would be better to simply retrain the people onto Java and do it properly.
> This gives the best of both worlds -- you can keep your Cobol source,
> but you can also seemlessly play in WS and other containers, or run just
> about anywhere. Its a win-win.
No it isn't. It's a nightmare. You end up with non-optimal Java being
"dragged down" because it is based on COBOL. And COBOL code that will never
be compiled or run, just for the sake of maintaining Business Rules in
COBOL... It would be FAR better to reformulate the Business Rules in Java,
encapsulating as many functions as possible into EJBs.
This simply illustrates my point about designing systems around the ease of
maintenance of source code. It is no longer a valid criterion. The ONLY
important thing is the effectiveness of the functionality. That is why
Objects will inherit the Network and procedural code will die.
Pete.
Peter E.C. Dashwood
"Stephen Gennard" <stephen...@microfocus.com> wrote in message
news:3EA649BE...@microfocus.com...
> I agree using EJBs for the business logic is a great but I don't see why
> you have to move your COBOL into Java when you can use the J2EE
> Connector architecture to access COBOL.
>
> All you need is a COBOL resource adapter...... which I am sure some
> vendor may provide sooner rather than later.
>
under CORBA or Windows (COM now supports EJBs and CORBA supports ActiveX, I
am reliably informed.)
Pete.
Peter E.C. Dashwood
> you have to move your COBOL into Java when you can use the J2EE
> Connector architecture to access COBOL.
>
> All you need is a COBOL resource adapter...... which I am sure some
> vendor may provide sooner rather than later.
>
under CORBA or Windows (COM now supports EJBs and CORBA supports ActiveX, I
am reliably informed.)
Pete.
Stephen Gennard
procedure call mechanism that can be used from a EJB container without
breaking its strict container isolation/integrity requirements.
Using these approaches work well for a non-transaction application that
do not want to obey J2EE security policy. But if you really want to
integrate with the J2EE environment itself, then a connector based
solution is the only way of being part of J2EE/EJB lifecycle.
--
Stephen
Stephen Gennard
Bob Wolfe
>This post made me think, Bob.
>
>I agree with you that translating well written COBOL to ANY other language
>is not productive.
>
>What it comes down to is whether you intend to maintain the code.
>
>If you do, then it makes sense to leave it in COBOL.
>
>The Management argument will be: "But we can't get COBOL programmers as they
>are a dying breed and the whole business of using COBOL is fraught with long
>delays over standards, and arguments about the value of various features in
>the language. We can get <language-du-jour> programmers because they are
>cheap and plentiful." (Or, in some cases they will use cheap COBOL labour
>sourced from the sub-continent...).
>
>The point is that if you intend to maintain source code, then COBOL is
>arguably the best language around for doing it.
>
>But the REAL requirement is NOT to maintain source code. It is to implement
>the business functions you require in as efficient a manner as possible.
>
Peter:
I agree completely with your statements, especially the objective to
avoid code maintenance. I'm positive that many companies have
achieved or have come very close to achieving this objective using OO.
We have also observed many ill-fated attempts at this in which the new
code is periodically re-written from scratch because it wasn't
properly written in the first place. Maintaining source can be a
better approach than a complete code re-write.....especially repeated
re-writes.
Each and every shop needs to assess their abilities and make a
carefully considered decision as to whether or not their shops'
strengths lie in one approach or the other......as well as whether or
not proper training/hiring will alleviate the weaknesses for the
desired approach, if it represents a departure from the status quo.
Ultimately it becomes a business decision on their part.....if they
don't care to retrain or hire programmers skilled in the desired
approach, then they should probably continue to utilize the approach
at which they have been successful.
There are too many starry-eyed PHM's who assume that a tool or a
methodology is the "magic bullet" and forget Mr. Mattias' wisdom that
"It's not the paintbrush, it's the artist."
Brian Sullivan
> "Joe Zitzelberger" <joe_zitz...@nospam.com> wrote in message
> news:joe_zitzelberger-63...@corp.supernews.com...
> > In article <3ea5c...@127.0.0.1>, "Peter E.C. Dashwood"
> > <dash...@enternet.co.nz> wrote:
> >
> > I can think of one specific case where it makes great sense to translate
> > the code into Java.
> >
> The example you give below is NOT "Great" sense...
>
> > Some Cobol folks at IBM have commented that while their JVMs are good
> > and their Java fast there is a significent performance price for
> > crossing the JVM barrier to call out to a non-JVM program. It is easy
> > and transparent, but you don't want to do it constintly.
>
> Performance is not a reason for converting. Beef up the hardware. (It is
> getting cheaper all the time...)
Coming from the PERCobol perspective, I'll offer some tidbits
throughout. (I was not one of the responders here previously, so
please don't misinterpret previously quoted material as mine.) These
comments were related to another product, a translator, and not
directly to ours, but I thought I should add a bit to avoid confusion.
I have stripped away quoted material for space, hopefully without
altering anyone's meaning.
Generally, yes, for performance you just add more hardware. Of
course, that has a cost as well, and the total cost is a
consideration.
I absolutely agree that translating the COBOL source into Java source
is not something you want to do. Targeting legibility,
maintainability and performance simultaneously in a translator is not
something I'd like to consider even after working on PERCobol for so
many years. We chose to target performance, and the ability to
maintain the source in COBOL while executing in the JVM. (That is, we
allow debugging in COBOL while executing in the JVM, editing of COBOL
in our IDE, listing files generated from the COBOL, etc.)
However, there are good reasons why compiling COBOL into the JVM (Java
Virtual Machine) makes sense, though.
The JVM can be treated just like any other hardware as a compilation
target. That's what we do from our perspective. It offers
competition on hardware, implementations, etc.
It makes sense if the existing platform is dead or just about to die.
We compile a large amount of COBOL code, including certain
environmental considerations (such as HP3000 VPLUS).
The JVM offers capabilities and new APIs sooner than traditional
environments. PERCobol programmers could do easy XML parsing almost
immediately. We have customers to whom the fact that it was running
on the JVM was irrelevant, we merely accepted their existing syntax
and offered additional features (additional platforms, additional
syntax, additional behavior, etc.).
The JVM offers application safety, both from crashes and malicious
behaviors. It's not perfect, because the JVM implementations are not
perfect, but it places all the difficult program behavior in one
location, below the application layer. (Yes, even plain COBOL is not
safe. Consider passing a PIC X(30) by reference to a program
expecting a PIC X(1000). Even without involving COBOL pointers, this
program may crash -- or read passwords or other sensitive data beyond
the bounds of the passed data. And, of course, if native it may link
in C or wreak other havoc upon the system.) By compiling COBOL to the
JVM, the COBOL code may safely operate even in the public application
servers without intruding upon other applications accidentally,
muchless maliciously. (And I should note that certain COBOL vendors
that claimed J2EE EJB from wrappered native COBOL were ignoring the
fact that J2EE explicitly forbids native code for these reasons. We
don't do wrappering for that.)
Lots of programmers now speak Java. A proper compilation to the JVM
means that the COBOL and Java programmers may both interact with one
another without realizing that they're not being called from the same
language, a good level of insulation. I come from the perspective
that one should use the appropriate language or tool for the task; if
the business logic is best done in COBOL and the EJB infrastructure
glue is best done in Java, so be it. (We also allow the EJB
infrastructure to be done in COBOL, treating it just like any other
external resource, such as calling to VPLUS, manipulating BMS, calling
to SQL, etc.)
> > So if you find yourself with an architecture built around EJBs, but you
> > want your business rules in Cobol, it might be worthwhile to convert the
> > Cobol to Java and generate business rules that can stay within the JVM
> > space.
>
> Yes, I agree with that. But you would not then maintain the Business rules
> in COBOL. (Why would you want to maintain TWO sets of Business Rules?)
Absolutely, maintaining two sets of business rules is horrible, if at
all avoidable.
> You COULD use a tool like perCOBOL to generate the Java from your COBOL
> (purely for the sake of performance and maintaining a single environment, if
> you are REALLY persuaded that this is important) but, as long as you try to
> maintain COBOL code as well as the EJBs, you have an unwieldy solution. It
> would be better to simply retrain the people onto Java and do it properly.
>
> Pete.
Here it seems that you're assuming that EJB implicitly means Java. It
only implicitly means the JVM (Java Virtual Machine), not Java the
language. You can fully code EJBs in OO COBOL using PERCobol, again,
like any other external dependency such as VSAM, VPLUS, BMS, DDS, etc.
In the Java world, there are JVMs capable of running Java programs,
mostly written in the Java programming language. However, they may
run Java programs written in COBOL or other languages as well (such as
Python).
Why do people look at COBOL on the JVM, either through compilers like
PERCobol or translators like certain others? Because COBOL and Java
truly are very similar in important respect, they are both application
programming languages. Not system programming languages, not logic
based, etc. but rather intended for programming applications. The
targets are the same. That's even why we keep seeing APIs evolve in
Java to target the same functionality present in COBOL environments,
such as EJBs and CICS.
In the COBOL world, there is the COBOL programming language, and then
there are all the environmental, external considerations. SQL,
presentation, file or other data, communications, CICS, etc. We're
just adding more options for the environment, such as EJBs, and
replicating existing environmental functionality where applicable and
practical (such as EXEC SQL accessing JDBC).
I'm just offering these comments in the light of the talk about a
certain translator which was muddying the waters, so I thought I'd
offer a bit of a clarification from my perspective.
Regards,
Brian Sullivan
Peter E.C. Dashwood
"Brian Sullivan" <bsu...@legacyj.com> wrote in message
news:f8041505.03042...@posting.google.com...
Interesting post Brian. I have expanded some of my ideas about the use of
PerCOBOL <G>.
I still see the future as OO, and I still like components as a solution
(that includes EJBs... irrespective of what they are written in...). I also
believe that overall development in the future will not use procedural
languages.
For the last year I have been working with some very bright people who are
the "new breed" of programmer. Their daily bread is SQL Server and Oracle;
their glue is VB and XML, their presentation layer is the Internet, and they
think in terms of, and manipulate only, Objects. I have seen them do things
in minutes which I would have expected to take days. They use tools that
COBOL programmers can only dream of (I can say this because I am one...<G>)
and their whole approach is light years ahead of the way in which we do
things. They have never seen any other way than Objects and OO.
A suite of COBOL programs to extract data from a Relational DB, manipulate
it, reformat it to other downstream programs and present it in the form of a
dozen reports and displays, we might reasonably expect to take a day or two,
including testing. I have seen it done with drag and drop in 10 minutes... I
thought I knew SQL until I looked at some of their stored procedures ...<G>
The world is changing and there will be no room for procedural code in the
future.
James J. Gavan
"Peter E.C. Dashwood" wrote:
>
> Interesting post Brian. I have expanded some of my ideas about the use of
> PerCOBOL <G>.
>
> I still see the future as OO, and I still like components as a solution
> (that includes EJBs... irrespective of what they are written in...). I also
> believe that overall development in the future will not use procedural
> languages.
>
> For the last year I have been working with some very bright people who are
> the "new breed" of programmer. Their daily bread is SQL Server and Oracle;
> their glue is VB and XML, their presentation layer is the Internet, and they
> think in terms of, and manipulate only, Objects. I have seen them do things
> in minutes which I would have expected to take days. They use tools that
> COBOL programmers can only dream of (I can say this because I am one...<G>)
> and their whole approach is light years ahead of the way in which we do
> things. They have never seen any other way than Objects and OO.
>
> A suite of COBOL programs to extract data from a Relational DB, manipulate
> it, reformat it to other downstream programs and present it in the form of a
> dozen reports and displays, we might reasonably expect to take a day or two,
> including testing. I have seen it done with drag and drop in 10 minutes... I
> thought I knew SQL until I looked at some of their stored procedures ...<G>
>
> The world is changing and there will be no room for procedural code in the
> future.
Like you I took a look at WINDEV and was, from a casual glance, impressed with what it
apparently offered. It seemed to me that it has that 'quick ten minute approach' that
you detailed above.
As to procedural code, I've only seen snapshots, but get the impression that
POWERCOBOL is a very powerful tool. As you've indicated in past posts, having
established your window/screen it then generates in effect an 'int'. I think there's
still a place for procedural COBOL as a business tool, PROVIDING each compiler vendor
continues to enhance by supplying add-on tools, within their IDEs, that let you
visually set things up but then generates the code. (As an aside, in N/E there's even
a tool that lets you define COBOL file formats - can't think why an old hand would
want to use it, but no doubt very useful for beginners).
Interesting background on Rainbow Warrior - for those of us old enough remember, but
naturally not the total details and fallout like you folks in the Antipodes. So I can
understand your reluctance to embrace a French product. It was interesting that you
said French was your THIRD language, (it's my own very half-baked second language,
having only spent some six hours in France at an air base at Istres, near Avignon, en
route to UK from Egypt). If there's one problem the French have - it is that French is
the THIRD language of all Europeans, excluding themselves and the Belgians. Having
scored a plus when it replaced Latin as the diplomatic language, they have never
forgiven perfide Albion, where those dreadful Anglo Saxons came to the fore.!
That has much to do with the shenanigans of UN Resolution 1441. (I still can't make up
my mind whose body language I detest most - Rumsfeld or Chirac). Ignoring the
rights/wrongs of Gulf War II, (perhaps WWE might be a better title - Weirdest War Ever
<G>), it is my hope that as part of Reconstruction the Yanks tell both the Russkies
and French to get stuffed, and kiss goodbye to the billions owed tied up in the Saddam
regime. Solution - Saddam's regime was yesterday - there will be a new Iraq which will
*not* acknowledge any outstanding debts - in a practical sense, that's the only way
the Iraqis can get back on their feet. (I saw a reference to the Spanish(Mexican
?)/American War where the combatants quit agreeing neither side owed anything in
reparations. Some US judge came up with a legal phrase, (it escapes me), that covered
this.
Jimmy