Prev: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
Next: Wildcat COBOL
From: Charles Hottel on 30 Oct 2007 19:44

<docdwarf(a)panix.com> wrote in message news:fg6u2d$qvk$1(a)reader1.panix.com...
>
> As an extension of an earlier thread regarding a COBOL-to-Java
> conversion... some meanderings.
>
> As noted, the core of such a thing is not a technology change, it is a
> business process change and needs to be addressed both by those familiar
> with the present process (what the COBOL system does) as well as those who
> are familiar with the new technology's capabilities (what the Java system
> can do). Right off the bat there may be difficulties... those familiar
> with the present process may respond with 'oh, we can do *that*, why
> didn't you ask?' when the new-tech team begins its proposals.
>
> I recall reading, someplace, a consultant who said he'd been approached by
> a small insurance company in the early 1970s about converting their
> current paper-and-pencil system to a state-of-the-art COBOL/CICS
> green-screen system. His off-the-record response was 'They wanted to
> duplicate their current processes... they had no idea how using a computer
> would change the way they work and the way they could work, essentially
> they wanted an electronic version of their current system and nothing
> more.'
>
> In like manner... who has not seen a DB2 installation obviously designed
> by VSAM-heads? All the overhead of an RDBM system, none of the benefits.
>
> The greatest difficulty, I would say, in these situations is that either
> marching-orders have already been given (some stinkwad, two-bit,
> Corner-Office Idiot says 'That last Executive Retreat I went to in the
> Bahamas - oh, the harsh burdens I bear for The Company! - taught that
> COBOL's worthless and Java's the way to go. Get it done!') or that those
> with a particular dog in the fight (Preserve the Olde Wayse or New System
> Now) are more interested in keeping discussion in areas that they know
> about than in honestly learning something new.
>
> (on my current site I do a lot of ad-hoc reporting and file-creation for a
> PeopleSoft system that gets ftp'd off the Big Iron... when it started the
> general attitude was 'Oh, that can't be done with COBOL'... and this has
> changed to 'Oh, only *he* can do that with COBOL', an equally distasteful
> view, I'd say)
>
> All in all, it is usually a good thing to remember what Machiavelli had to
> say about the introduction of new systems
> <http://www.gutenberg.org/files/1232/1232.txt>
>
> --begin quoted text:
>
> And it ought to be remembered that there is nothing more difficult to take
> in hand, more perilous to conduct, or more uncertain in its success, then
> to take the lead in the introduction of a new order of things. Because the
> innovator has for enemies all those who have done well under the old
> conditions, and lukewarm defenders in those who may do well under the new.
> This coolness arises partly from fear of the opponents, who have the laws
> on their side, and partly from the incredulity of men, who do not readily
> believe in new things until they have had a long experience of them.
>
> --end quoted text
>
> DD
>

I have learned that we now have around 860 contractors working on our "new"
system. I put new in quotes because the current system was used for the
specifications for the new system. That 860 number is after they got rid of
a lot of SAP people. They tried to replace one subsystem with 80% vanilla
SAP and 20% ABAP, but the vanilla SAP could not do even 60%. All of this
just to say they no longer have COBOL and now have the new and improved and
20% to 30% slower state of the art Java. In one lunch room they have a huge
chart of system development processes and paperwork deliverables. If you
live in the USA then sorry, it it your tax dollars at work :-(


From: Charles Hottel on 30 Oct 2007 19:48

"HansJ" <hjigel(a)kup.de> wrote in message
news:1193755022.300465.265380(a)k79g2000hse.googlegroups.com...
> On 30 Okt., 14:20, Rene_Surop <infodynamics...(a)yahoo.com> wrote:
>> Considering HansJ situation..... and with such a magnitude of
>> requirements. Woh! System language conversion is not my best solution.
>> Go to the Cobol vendor who provided the solutions and re-engineer.
>>
>> If business logic is needed to be changed... then start with a "new"
>> language platform "you think" is best and IT people have "several"
>> solutions for it.
>>
>> Best practice: Go to a Cobol provider.... or Java-based vendor for re-
>> engineering. Definitely you have a budget for it. Get several vendor
>> solutions for re-engineering and concentrate even more with budgets.
>>
>> http://www.computerworld.com.au/index.php/id;1914725230;fp;;fpid;;pf;1
>>
>> A link above would somehow help... but then again, somehow?!? Most
>> successful developers knew Cobol, that is why we are here in this
>> Cobol Google group anyway.
>
> Rene,
> I'm not advocating to convert a COBOL application to Java, I like to
> know if anyone has seen a successful project od this type.
>
> This question was raised because of a requirement in an RFP that
> included that the target language would be Java where the original
> language was COBOL (Unisys UCOB).
>
> Regards HansJ
>

I don't know about COBOL to Java. We are doing it at work now but it will
take many years before it will succeed or fail. Actuall I can tell you now
that because of the huge amount of money being spent it will be called a
success even if it fails.

You can go from COBOL to Java byte code user PerCOBOL. Although I have not
used it those I know who have say it works well.


From: Anonymous on 30 Oct 2007 20:16
In article <5opm2vFnnl68U1(a)mid.individual.net>,
Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote:
>
>
><docdwarf(a)panix.com> wrote in message news:fg6u2d$qvk$1(a)reader1.panix.com...

[snip]

>> All in all, it is usually a good thing to remember what Machiavelli had to
>> say about the introduction of new systems
>> <http://www.gutenberg.org/files/1232/1232.txt>
>>
>> --begin quoted text:
>>
>> And it ought to be remembered that there is nothing more difficult to take
>> in hand, more perilous to conduct, or more uncertain in its success, then
>> to take the lead in the introduction of a new order of things.
>
>Only if you're a sissy. REAL Men embrace change and have no problem with
>being responsible for it. :-)

Just like military officers have no problems leading their men over the
tops of the trenches... and the Gallipoli-like results which may ensue.

>
>> Because the
>> innovator has for enemies all those who have done well under the old
>> conditions, and lukewarm defenders in those who may do well under the new.
>
>And should be lobbying both camps with the promises of the new and
>explaining how this change will benefit all concerned.

That might be the case, as well... but for me, I will leave lobbying to
the lobbyists and selling to the salesfolk; they have their jobs and I
have mine.

>
>> This coolness arises partly from fear of the opponents, who have the laws
>> on their side, and partly from the incredulity of men, who do not readily
>> believe in new things until they have had a long experience of them.
>
>That's part of a leader's job; address their incredulity and convert it into
>support. Part of the challenge is to motivate people to be at worst,
>non-committal ("Ok, let's wait and see..."), at best, enthusiastic, to see
>new systems.

'Over the top, boys... I'll lead the way!'

>
>Although there may be SOME parallels between Renaissance Italy and the
>modern Business World, for the most part, they are different. Machiavelli
>would be out of his depth in the politics, subtleties, and complexity of
>modern Board Rooms.

I'll take that as the Voice of Experience, one that spent much time in
Renaissance Italy. I don't know many folks who spent time in modern Board
Rooms who have become Pope, as did Rodrigo Borgia.

DD

From: HeyBub on 30 Oct 2007 20:57
Charles Hottel wrote:
>
> I have learned that we now have around 860 contractors working on
> our "new" system. I put new in quotes because the current system was
> used for the specifications for the new system. That 860 number is
> after they got rid of a lot of SAP people. They tried to replace one
> subsystem with 80% vanilla SAP and 20% ABAP, but the vanilla SAP
> could not do even 60%. All of this just to say they no longer have
> COBOL and now have the new and improved and 20% to 30% slower state
> of the art Java. In one lunch room they have a huge chart of system
> development processes and paperwork deliverables. If you live in the
> USA then sorry, it it your tax dollars at work :-(

This echos what I've learned from long experience.

A large system designed from scratch will not work and cannot be made to
work. You have to start over with a working, smaller system. However, a
large system, produced by expanding the dimensions of a smaller system, does
not behave like the smaller system.

In a large system, malfunction, or even total non-function, may not be
detectable for long periods, if ever. The total behavior of large systems
cannot be predicted.

Some complex systems actually work. If a system is working, leave it alone.

In setting up a new system, tread softly. You may be disturbing another
system that is actually working.


From: Robert on 31 Oct 2007 00:52
On Tue, 30 Oct 2007 19:44:40 -0400, "Charles Hottel" <chottel(a)earthlink.net> wrote:

>I have learned that we now have around 860 contractors working on our "new"
>system. I put new in quotes because the current system was used for the
>specifications for the new system. That 860 number is after they got rid of
>a lot of SAP people.

SAP people are usually very good, and very expensve. IBMers are just very expensive.

>They tried to replace one subsystem with 80% vanilla
>SAP and 20% ABAP, but the vanilla SAP could not do even 60%.

SOA is about turning the old code into a Service, rather than rewriting it.

>All of this
>just to say they no longer have COBOL and now have the new and improved and
>20% to 30% slower state of the art Java.

SAP is written in C and ABAP, not Java. If it's only 20-30% slower, it's better than most
new systems, which are typically 2-3 TIMES slower. Tuning often produces dramatic
improvements in speed.

>In one lunch room they have a huge
>chart of system development processes and paperwork deliverables.

In the old days, deliverables were things like Code Complete and Integration Testing
Passed. Now, deliverables are paperwork attesting to those milestones. Someone should ask
why, if development was complete two months ago, they're still making code changes.

>If you live in the USA then sorry, it it your tax dollars at work :-(

"Pessimist drowns in half empty bathtub." :)

YOU could be one of those 860 contractors. If you can't beat 'em, join 'em.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
Next: Wildcat COBOL