Prev: Modernizing COBOL
Next: How to convert this Vb code to Netcobol Code
From: Chuckles55 on 4 Jan 2010 14:19
Hi Everyone,

Management has again made it very clear (that) they don't want a major
recode until the ultimate target system (not necessarily Windows), for
an individual existing z/OS job (JCL+COBOL+DFSort code), has been
chosen. Thus, management has decided we will re-host to a cheaper
environment as an interim step using a solution with the least change
to existing z/OS code. Management would then have time to decide upon
the appropriate (e.g. non-IBM COBOL environment or Windows) target
system.

The Alchemy (Fujitsu) option of NetCobol+NeoBatch+NeoSort is looking
like the most attractive option. As we understand it, our JCL, COBOL,
and SORT code would execute largely unchanged within a NeoBatch
environment.

Thanks again for your ideas, comments, and discussion,
Chuck
From: Pete Dashwood on 4 Jan 2010 16:56
Chuckles55 wrote:
> Hi Everyone,
>
> Management has again made it very clear (that) they don't want a major
> recode until the ultimate target system (not necessarily Windows), for
> an individual existing z/OS job (JCL+COBOL+DFSort code), has been
> chosen. Thus, management has decided we will re-host to a cheaper
> environment as an interim step using a solution with the least change
> to existing z/OS code. Management would then have time to decide upon
> the appropriate (e.g. non-IBM COBOL environment or Windows) target
> system.
>
> The Alchemy (Fujitsu) option of NetCobol+NeoBatch+NeoSort is looking
> like the most attractive option. As we understand it, our JCL, COBOL,
> and SORT code would execute largely unchanged within a NeoBatch
> environment.
>
> Thanks again for your ideas, comments, and discussion,

For what you have outlined, this is a good solution.

However, long term, it doesn't move you forward. Still, it is likely that
"Management" are only looking to get off the current platform at this stage,
and that is probably the best option for doing it.

These are good tools and a good environment.

Long term you need to be thinking objects and layers.

Please refer "Management" to http://primacomputing.co.nz/PRIMAWebSite where
strategic as well as tactical implications are discussed...

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


From: Paul on 4 Jan 2010 21:05
On 2010-01-04 13:19:35 -0600, Chuckles55 <chuckmoore55(a)gmail.com> said:

> Hi Everyone,
>
> Management has again made it very clear (that) they don't want a major
> recode until the ultimate target system (not necessarily Windows), for
> an individual existing z/OS job (JCL+COBOL+DFSort code), has been
> chosen. Thus, management has decided we will re-host to a cheaper
> environment as an interim step using a solution with the least change
> to existing z/OS code. Management would then have time to decide upon
> the appropriate (e.g. non-IBM COBOL environment or Windows) target
> system.
>
> The Alchemy (Fujitsu) option of NetCobol+NeoBatch+NeoSort is looking
> like the most attractive option. As we understand it, our JCL, COBOL,
> and SORT code would execute largely unchanged within a NeoBatch
> environment.
>
> Thanks again for your ideas, comments, and discussion,
> Chuck

I must say, the Fujitsu compiler is, in my opinion, quite impressive.
However, the Alchemy people
have not proven easy or reasonable to deal with. While they do not
have runtimes, I question if their
actual pricing would be reasonable.

I would definitely go look at the PerCOBOL stuff - the transition might
not be quite as smooth,
but I believe the people behind it would put out a lot more effort to
make you successful.

And the good part? You could run the converted code in a Linux
instance on the mainframe
if you wanted to. :)

-Paul

From: Clark F Morris on 4 Jan 2010 21:37
On Mon, 4 Jan 2010 11:19:35 -0800 (PST), Chuckles55
<chuckmoore55(a)gmail.com> wrote:

>Hi Everyone,
>
>Management has again made it very clear (that) they don't want a major
>recode until the ultimate target system (not necessarily Windows), for
>an individual existing z/OS job (JCL+COBOL+DFSort code), has been
>chosen. Thus, management has decided we will re-host to a cheaper
>environment as an interim step using a solution with the least change
>to existing z/OS code. Management would then have time to decide upon
>the appropriate (e.g. non-IBM COBOL environment or Windows) target
>system.

Have they investigated the latest "Do we have a deal for you" offers
from IBM on the z series? Given the capabilities of IFL LPARs and zVM
certain Linux loads can be hosted on the mainframe very cost
effectively (I wouldn't try Google on it or any other very compute
intensive work). IBM is improving the Java capabilities all the time
and using the smoke and magic of specialty processors, sometimes
enough work can be moved to them in a way to decrease overall software
charges.
>
>The Alchemy (Fujitsu) option of NetCobol+NeoBatch+NeoSort is looking
>like the most attractive option. As we understand it, our JCL, COBOL,
>and SORT code would execute largely unchanged within a NeoBatch
>environment.
>
>Thanks again for your ideas, comments, and discussion,
>Chuck
From: Clark F Morris on 4 Jan 2010 21:41
On Tue, 5 Jan 2010 10:56:57 +1300, "Pete Dashwood"
<dashwood(a)removethis.enternet.co.nz> wrote:

>Chuckles55 wrote:
>> Hi Everyone,
>>
>> Management has again made it very clear (that) they don't want a major
>> recode until the ultimate target system (not necessarily Windows), for
>> an individual existing z/OS job (JCL+COBOL+DFSort code), has been
>> chosen. Thus, management has decided we will re-host to a cheaper
>> environment as an interim step using a solution with the least change
>> to existing z/OS code. Management would then have time to decide upon
>> the appropriate (e.g. non-IBM COBOL environment or Windows) target
>> system.
>>
>> The Alchemy (Fujitsu) option of NetCobol+NeoBatch+NeoSort is looking
>> like the most attractive option. As we understand it, our JCL, COBOL,
>> and SORT code would execute largely unchanged within a NeoBatch
>> environment.
>>
>> Thanks again for your ideas, comments, and discussion,
>
>For what you have outlined, this is a good solution.
>
>However, long term, it doesn't move you forward. Still, it is likely that
>"Management" are only looking to get off the current platform at this stage,
>and that is probably the best option for doing it.
>
>These are good tools and a good environment.
>
>Long term you need to be thinking objects and layers.

The ironic thing is that thinking in objects and layers can be done
using the z series. There are C/C++ classes for CICS. IBM has been
preaching layers for at least 20 years. Unfortunately many
managements refuse to get out the COBOL 74 mindset and then wonder why
the mainframe is obsolete. The mainframe isn't and they are.
>
>Please refer "Management" to http://primacomputing.co.nz/PRIMAWebSite where
>strategic as well as tactical implications are discussed...
>
>Pete.
 |  Next  |  Last
Pages: 1 2 3
Prev: Modernizing COBOL
Next: How to convert this Vb code to Netcobol Code