Prev: COBOL Error Handling (was: What MF says about ROUNDED(was:Cobol Myth Busters
Next: Wildcat COBOL
From: Rene_Surop on 30 Oct 2007 09:20
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.

From: HansJ on 30 Oct 2007 10:37
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

From: Bill Gunshannon on 30 Oct 2007 11:10
In article <1193755022.300465.265380(a)k79g2000hse.googlegroups.com>,
HansJ <hjigel(a)kup.de> writes:
> 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).
>

Well, now that I know this is in answer to an RFP, I can put on my
contractor hat (after dusting it off as I haven't been in that world
for over two decades) and suggest bringing up my question to the
person putting out the RFP and if the answer is either inadequate
or demonstrates a complete lack of knowledge on the subject by the
proposing organization, a "no bid" might be the correct answer.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill(a)cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
From: HansJ on 30 Oct 2007 12:44
On 30 Okt., 16:10, b...(a)cs.uofs.edu (Bill Gunshannon) wrote:
> In article <1193755022.300465.265...(a)k79g2000hse.googlegroups.com>,
> HansJ <hji...(a)kup.de> writes:
>
>
>
> > 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).
>
> Well, now that I know this is in answer to an RFP, I can put on my
> contractor hat (after dusting it off as I haven't been in that world
> for over two decades) and suggest bringing up my question to the
> person putting out the RFP and if the answer is either inadequate
> or demonstrates a complete lack of knowledge on the subject by the
> proposing organization, a "no bid" might be the correct answer.
>
> bill
>

we did not bit.

You might be correct with your assumption "demonstrates a complete
lack of knowledge on the subject".

Regards HansJ

> --
> Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
> b...(a)cs.scranton.edu | and a sheep voting on what's for dinner.
> University of Scranton |
> Scranton, Pennsylvania | #include <std.disclaimer.h>


From: Pete Dashwood on 30 Oct 2007 17:30


<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.

Only if you're a sissy. REAL Men embrace change and have no problem with
being responsible for it. :-)

> 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.

> 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.

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.

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



 |  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