From: Pakku on
On May 2, 7:48 pm, "Pete Dashwood"
<dashw...(a)removethis.enternet.co.nz> wrote:
> <docdw...(a)panix.com> wrote in messagenews:fvg4ic$i42$1(a)reader2.panix.com...
> > In article
> > <e6e414bd-2cd7-4ddb-b4a8-f70c7804b...(a)k13g2000hse.googlegroups.com>,
> > Pakku <pa...(a)soccermail.com> wrote:
> >>On May 2, 1:40 pm, docdw...(a)panix.com () wrote:
> >>> In article
> >>> <8f50322e-2160-4e05-89e1-fb383ab4c...(a)27g2000hsf.googlegroups.com>,
>
> >>> Pakku <pa...(a)soccermail.com> wrote:
> >>> >I've spent much of this morning looking for some comparison between
> >>> >the performance of Java and COBOL for batch programming on z/OS.
>
> >>> Other people have been looking for data about this, in order to help
> >>> very
> >>> large corporations make/save very large amounts of money, for a good,
> >>> long
> >>> time.
>
> >>> >I
> >>> >haven't found any useful information and am hoping I might find some
> >>> >here.
>
> >>> Nothing here but text and words... put together a good PowerPoint
> >>> presentation and you'll get the contract.
>
> >>No contract involved, I am afraid. Just a humble grunt who shot off
> >>his mouth in a meeting that Java batch programs/processes are sucky on
> >>MVS and now trying to find something to back me up!
>
> > Hmmmm... aside from the caution of 'make sure that brain is engaged before
> > putting mouth in gear'... how about something like 'I spent twenty whole
> > minutes (or an equivalently impressive amount of time) searching the Web
> > and found *nothing* that would indicate any kind of superiority'?
>
> >>While I am all for SOA and WebServices and real-time, I just don't get
> >>how we will send out bills to 200K clients each month in any fashion
> >>other than a batch process that runs at month-end.
>
> > You might want to speak with Mr Dashwood about that... maybe *he* will get
> > the contract.
>
> Sorry, I'm already very busy at the moment...:-)
>
> However, it may be that the OP's fears about Java sucking at batch are not
> entirely justified.
>
> There seems to be some very pertinent comment here:http://www.devx.com/Java/Article/20791
>
>
>
> >>And to rewrite
> >>existing program from Cobol in Java just because some policy-wonk
> >>mandated that we will be an all-Java shop in 5 years...
>
> If becoming an all Java shop saves millions of dollars overall, you can't
> blame them for doing it. Of course, I have no trouble seeing the Big
> Picture...:-)
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."


Pete- the link you provided ties into a couple of articles on the
Spring Framework for batch processing that I came across. That
product is quite new, less than a year old but as to saving millions
of dollars overall, not so sure...

In my peregrinations across the web I came across these links
http://groups.google.com/group/bit.listserv.ibm-main/browse_thread/thread/ad3cb116af4b2468/55681a34310115a5?hl=en&lnk=st&q=java+batch+performance+on+the+mainframe#55681a34310115a5
Here he talks about the interpreted v compiled issue but his post is
from 6 years back and going by what I have read here, not correct any
more

In this link, one poster quotes a Forester Research article...
http://groups.google.com/group/bit.listserv.ibm-main/browse_thread/thread/15f93e7ee53e0172/978a077493616408?hl=en&lnk=st&q=java+batch+on+zos#978a077493616408
'Rewriting code is about the most expensive thing you can do in all of
IT. Phil Murphy, analyst at Forrester Research, says that "replacing
COBOL for the sake of technical change
provides no business value. The days when IT can get away with that
kind
of expenditure are gone -- if it provides no business value, it
shouldn't
be funded." '

And in this link here
http://groups.google.com/group/bit.listserv.ibm-main/browse_thread/thread/152a527413b665e5/1572d84d3be6c7d1?hl=en&lnk=st&q=java+batch+performance+on+the+mainframe#1572d84d3be6c7d1
he says
"Changing platforms is always much harder and much more expensive than
most
can imagine. For most, rewriting their application suite is
prohibitively
costly. Almost all migrations from a mainframe platform to any client
server
model have been expensive disasters. "

But as DD said, I am more than happy to smile and go along with the
guy who signs my paycheque!
From: Pakku on
On May 2, 4:01 pm, Thomas Zierer <Thomas.Zie...(a)muenchen-mail.de>
wrote:
> JZOS has become part of Unix System Services in z/OS. Handling is very
> easy, especially if combined with other Java tools like ANT. There is an
> interesting sample shiped with JZOS: Installing an running a Apache
> Tomcat server as a batch job or started task. It really takes only a few
> minutes to get the server up and running.
>
> I havn't made any research on performance, but the last I've heard is
> that Java is about 30% slower as COBOL, which is reduced, if your S/390
> uses special chips. Also IMS uses now special regions, JMPP and JBMP for
> Java apps but I'be have no experience with this.
>
> Regards
>
> Thomas
>
We don't have the zAAP processor or any plans to get one. Will have
to find out more about that 30% number though.
Tx
From: Anonymous on
In article <6d275d43-2aa1-46b6-a913-5dbd5d72b6cc(a)m44g2000hsc.googlegroups.com>,
Pakku <pakku(a)soccermail.com> wrote:

[snip]

>But as DD said, I am more than happy to smile and go along with the
>guy who signs my paycheque!

zzzzZZZzzzz... eh? whuh? Actually... that's not quite my formulation,
which is usually somewhere along the lines of... let's see... ahhhh, from
over a decade back,
<http://groups.google.com/group/comp.lang.cobol/msg/aee256cd6bdd410a?dmode=source>

--begin quoted text:

Point well taken, old boy, but that is already covered by DocDwarf's Law
of Well-Functioning Systems, viz. -

'A Well-Functioning System is one which causes the person who has the
most say over signing the checks to smile.'

--end quoted text

Note that you are not the one who is to smile. You are to shriek and
howl and jump up and down and scream things like 'that would destroy the
audit-trail!' and 'are you trying to keep your General Ledger in
pencil?' and other things that show you behave as though Data Are Sacred.

Then, after you Get Something In Writing, you are to do what is needed to
keep the person signing the check/ques smiling.

DD

From: Clark F Morris on
On Fri, 02 May 2008 22:01:10 +0200, Thomas Zierer
<Thomas.Zierer(a)muenchen-mail.de> wrote:

>JZOS has become part of Unix System Services in z/OS. Handling is very
>easy, especially if combined with other Java tools like ANT. There is an
>interesting sample shiped with JZOS: Installing an running a Apache
>Tomcat server as a batch job or started task. It really takes only a few
>minutes to get the server up and running.
>
>I havn't made any research on performance, but the last I've heard is
>that Java is about 30% slower as COBOL, which is reduced, if your S/390
>uses special chips. Also IMS uses now special regions, JMPP and JBMP for
>Java apps but I'be have no experience with this.

This gets complicated and speaks as much to IBM marketing as anything
else. Java batch may well take 30 to 50 percent more CPU yet cost
less because the Java is run on a zAAP which doesn't count toward
capacity when calculating software pricing. If someone got bright on
some of the Java functions, this may be even less. IBM pricing can be
a driving factor to moving to another language. What the marketing
droids fail to realize is that once all of an installations work load
is moved to C/C++, Java and the web, it becomes easy to move to
another platform. Of course it is harder to move to another language
than the enthusiasts of X claim. This is especially true if people
don't really know how the current system operates, down to the various
subtleties. I wonder if any organization knows even a good percentage
of their components and the implications of interaction. The number
of fixes needed for any of the operating systems of affliction or
choice from the various vendors leaves me skeptical.
>
>Regards
>
>Thomas
>
>
>Pakku schrieb:
>> I've spent much of this morning looking for some comparison between
>> the performance of Java and COBOL for batch programming on z/OS. I
>> haven't found any useful information and am hoping I might find some
>> here.
>>
>> I know that IBM bought the JZOS product a couple years back with the
>> intent of enabling Java in the batch world.
>> Has this taken off?
>>
>> Also read somewhere that given that Java has to be reinterpreted (from
>> the bytecode produced by compilation) by the JVM at runtime, there is
>> no way it could outperform COBOL in classical batch processes like
>> payroll or month-end credit card statement processing.
>>
>> Is this so?
>>
>> Would really appreciate hearing from anyone who has experience with
>> JZOS or other forms of running batch Java on MVS.
>>
>> Thanks!
From: Robert on
On Mon, 5 May 2008 10:30:13 -0700 (PDT), Pakku <pakku(a)soccermail.com> wrote:

>And in this link here
>http://groups.google.com/group/bit.listserv.ibm-main/browse_thread/thread/152a527413b665e5/1572d84d3be6c7d1?hl=en&lnk=st&q=java+batch+performance+on+the+mainframe#1572d84d3be6c7d1
>he says
>"Changing platforms is always much harder and much more expensive than
>most
>can imagine. For most, rewriting their application suite is
>prohibitively
>costly. Almost all migrations from a mainframe platform to any client
>server
>model have been expensive disasters. "

Changing the platform, say from mainframe to Unix server, does not require a rewrite, it
requires a recompilation. It is not true that "almost all migrations ... have been
expensive disasters." I've worked on a few dozen migrations that went smoothly, and am
aware of hundreds of others. I've never worked on a migration that was abandoned. The only
expensive disasters were to IBM salesmen's commissions.

The Micro Focus Cobol compiler is VERY compatible with IBM mainframe Cobol. It is common
for programs to compile and run on Unix without a single change being required. Rewriting
JCL into shell script is easy because JCL has very little logic. Basically it lists
programs and their files, if any. Utilities such as sorts and SQL tools have one-for-one
equivalents e.g. there is a Unix version of SyncSort.