From: Arnold Trembley on
Pakku wrote:
> 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

JZOS seems to be a product that comes highly recommended. I don't
really know anything about it, although I have met Kirk Wolf, who may
be author of JZOS.

I have heard an anecdote that Java on z/OS also uses considerably more
memory than a corresponding batch COBOL job (hundreds of megabytes)
but I don't have any direct experience with that.


--
http://arnold.trembley.home.att.net/
From: Howard Brazee on
On Mon, 05 May 2008 22:22:00 -0500, Robert <no(a)e.mail> wrote:

>Changing the platform, say from mainframe to Unix server, does not require a rewrite, it
>requires a recompilation.

I've read about this theory - especially with regards to CoBOL. But
I've done lots of real-world conversions, and they have all required
rewrites.

I guess this is because switching to new platforms has always been
accompanied by bigger business changes than just finding a new
computer.
From: chuck on
On May 5, 11:22 pm, Robert <n...(a)e.mail> wrote:
> On Mon, 5 May 2008 10:30:13 -0700 (PDT), Pakku <pa...(a)soccermail.com> wrote:
> >And in this link here
> >http://groups.google.com/group/bit.listserv.ibm-main/browse_thread/th...
> >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.

I think you speak rather glibly here...I don't have much experience
but know of at least one project- to convert from the 3rd millennium
version of a hardware platform to the 9th millennium version of the
same hardware that is months behind and beacoup bucks over. Part of
it had to do with a proprietary dbms but not all.
Oddly enuff Net Express is the development tool involved!

But attempts at conversions get bogged down with changed business
specifications. As soon as system users hear there is going to be a
conversion they want all these new requirements to be incorporated-
kind of like "While you are in there making this change, why not make
this additional teensy change as well" that most programmers know
about!
From: Anonymous on
In article <b771707f-7b70-4d26-a01d-ccd21d0e6ef5(a)m3g2000hsc.googlegroups.com>,
chuck <charles.leviton(a)gmail.com> wrote:

[snip]

>As soon as system users hear there is going to be a
>conversion they want all these new requirements to be incorporated-
>kind of like "While you are in there making this change, why not make
>this additional teensy change as well" that most programmers know
>about!

Ahhhhhh, the ever-popular 'Well, I'm not (*sniff*) technical... but *I*
don't see what the Big Deal about it is.'

(to which one responds 'Well, the Big Deal is... something technical.')

DD

From: Pete Dashwood on


"chuck" <charles.leviton(a)gmail.com> wrote in message
news:b771707f-7b70-4d26-a01d-ccd21d0e6ef5(a)m3g2000hsc.googlegroups.com...
> On May 5, 11:22 pm, Robert <n...(a)e.mail> wrote:
>> On Mon, 5 May 2008 10:30:13 -0700 (PDT), Pakku <pa...(a)soccermail.com>
>> wrote:
<snip>
>
> But attempts at conversions get bogged down with changed business
> specifications. As soon as system users hear there is going to be a
> conversion they want all these new requirements to be incorporated-
> kind of like "While you are in there making this change, why not make
> this additional teensy change as well" that most programmers know
> about!

Yeah, users are the pits... Always wanting something, never satisified.

They despise techies and don't even try to understand the basics.

They just don't seem to get it. Computer systems are there for us to improve
our skills. So we can go down the road and get even more money for not
providing service.

And what's with this "It's great, but can we just have this one small
change...?" We sweat blood to give them what they told us they wanted when
we did the requirements gathering, and then when we deliver it, they want it
changed.

Like we should be responsive to them changing their minds. As if we had
nothing better to do than be at their beck and call all day.

It's time they figured out who the dog is and who the tail is around here.
We can bring them to a standstill any time we want.

They don't understand the awesome responsibility we have to carry every day.
And all we ask is for them to be clear in what they want and be glad when we
deliver it, even if it is no longer relevant. Not our fault if the business
changes and the markets change and the technology changes and what they
needed before isn't what they need now... THEY signed off the functional
spec. ('Course, we wouldn't have started work if they hadn't...)

Nah, don't talk to me about users.

Bloody wimpy little cry-babies who're never satisfied...

Pathetic.

Pete.
-
"I used to write COBOL...now I can do anything."