Prev: "Hello World" OpenCobol query
Next: "Climategate" code
From: Charles Hottel on 25 Nov 2009 16:18

"Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message
news:7n4jriF3jqndeU1(a)mid.individual.net...
> Chuckles55 wrote:
>> Hi Everyone,
>>
>> My organization wants to move its IBM z/OS COBOL programs off onto
>> another (perceived-to-be cheaper) platform. One option being discussed
>> is converting the (400+) programs (most of which do financial
>> crunching to create print files) to run on Windows using either
>> MicroFocus COBOL or Fujitsu NETCOBOL. There will be 2-4 programmers on
>> the conversion team.
>> My questions:
>> 1) Does anyone here have a preference between MicroFocus and Fujitsu ?
>
> Far too much to cover in detail here.
>
> 1. Fujitsu has no runtime fees and you do not require the .NET COBOL
> compiler. The software is excellent. (So is MicroFocus, but my preference
> would be Fujitsu.)
>
>> 2) If anyone has done conversions like this, how were DD statement
>> (let alone IDCAMS) functionality converted ? (i.e. pass file
>> descriptions in as XML ?, use ISAM on Windows ?)
>
> 1. Automatically convert the VSAM (KSDS) Files to Relational Database
> (Data Conversion - fully automated).
>
> 2. Load your existing VSAM data to the new table sets. (Load Module
> generation and Loading - fully automated)
>
> That completes data conversion. Now you can access your DB with standard
> software as well as COBOL. The report programs can be systematically
> replaced with tools designed for reporting (Crystal Reports, StimulSoft,
> etc.)... or not. Your choice. At least you have some options...
>
> 3. Generate a Data Access Layer of Objects to access the RDB table sets.
> (DAL objects in OO COBOL that carry out all the access the VSAM verbs used
> to.) These objects are generated from your RDB table set definitions. This
> separates the data layer from the Business logic without any real effort
> on your part. The objects are multi-threaded and can be invoked easily
> from COBOL and any other languages that support the Component Object
> Model. You can access your new DB easily from new COBOL apps, Web Pages,
> or new apps written in new languages, separately or conjointly. (fully
> automated)
>
> 4. Amend the application programs to replace all the VSAM access with
> invokes of the DAL objects generated in 3 above. (over 95% automated -
> some minor manual amendments in extreme cases, for very complex or
> non-COBOL 85 compliant code.)
>
> At this point both Data and Code Conversion is complete. You have a system
> that runs on the new networked platform under .NET, accesses a relational
> database in a separate tier, and the existing applications function
> exactly as they always have, except that now they are accessing the new
> RDB instead of VSAM KSDS.
>
> (Although you CAN use ISAM under Windows as a VSAM equivalent, Relational
> Databases are preferable because they are open, standardised, and
> scalable.) Of course, if you can get them automatically, without any
> manual effort, generated from your exisiting COBOL copybooks, that is just
> another reason for going that way. The Toolset generates normalised DB
> tables, along with modules to load them, all from your existing legacy
> COBOL codebase, in seconds.
>
> NEW applications can be developed on the Web or .NET using COBOL or
> whatever other languages you may want to use.
>
> If you are currently using CICS, you may want to replace this with ASP.NET
> or WPF or simple WinForms. Fujitsu offer NeoKICKS, but this DOES require
> the .NET COBOL compiler.
>
> The converted system runs under .NET using SQL Server or your RDBMS of
> choice.
>
>>
>> Any further comments or suggestions would be appreciated,
>
> Please see http://primacomputing.co.nz/cobol21/mig.aspx and
> http://primacomputing.co.nz/cobol21/PRIMAToolset.aspx which describe the
> background to the outline above.
>
> My personal opinion:
>
> It is fairly easy to "transfer" an existing COBOL system to a different
> platform. (Whether that platform is networked workstations or a new
> central processing site.) However doing this simply takes time, money, and
> energy and provides no LONG TERM relief. You might as well address
> conversion as a complete Migration, and go for objects and layers which
> will see you well into the future (as well as being much more viable in
> today's networked environments.) Objects and layers allow you to use other
> languages and tools besides COBOL. Re-factoring your existing code means
> you can usually (not always...) save a good percentage of the cost of
> rebuilding everything from scratch.
>
> I started moving off COBOL around 4 years ago and encountered all the
> problems described on the web site. I started writing tools to help me,
> and since then have assisted other people to undertake the same migration.
> Today I develop in C#, but I still have a number of legacy COBOL
> components that are still doing the jobs they have always done. As time
> and money permits, I'll gradually replace them, but refactoring this
> functionality into objects has bought me time and eased the transition
> into "New Technology".
>
> The PRIMA Toolset automatically creates objects and layers from existing
> legacy code. I don't know any other conversion/migration tools that do
> that.
>
> Good luck with whatever you decide.
>
> Pete.

They want to do this where I work also. They call it re-hosting. The goal
is to get everything off the mainframe by 09-30-20014. I was told that all
of the work is being contracted out to MicroFocus. The main problem here is
Datacomm DB which only runs on the mainframe and the Datacomm DB code is
entwined within the program.. I think they will extract it by creating a
data access layer. It will have to be replaced with a relational DB. I
think they are going with Oracle.

I guess the replacement system development is taking too long and they want
to save money on hardware and I believe they consider Datacomm DB to be
expensive also. There are plenty of horror stories about problems with the
software developed so far for the replacement system. I will spare you the
details for now.


From: Pete Dashwood on 25 Nov 2009 19:07
Charles Hottel wrote:
> "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote in message
> news:7n4jriF3jqndeU1(a)mid.individual.net...
>> Chuckles55 wrote:
>>> Hi Everyone,
>>>
>>> My organization wants to move its IBM z/OS COBOL programs off onto
>>> another (perceived-to-be cheaper) platform. One option being
>>> discussed is converting the (400+) programs (most of which do
>>> financial crunching to create print files) to run on Windows using
>>> either MicroFocus COBOL or Fujitsu NETCOBOL. There will be 2-4
>>> programmers on the conversion team.
>>> My questions:
>>> 1) Does anyone here have a preference between MicroFocus and
>>> Fujitsu ?
>>
>> Far too much to cover in detail here.
>>
>> 1. Fujitsu has no runtime fees and you do not require the .NET COBOL
>> compiler. The software is excellent. (So is MicroFocus, but my
>> preference would be Fujitsu.)
>>
>>> 2) If anyone has done conversions like this, how were DD statement
>>> (let alone IDCAMS) functionality converted ? (i.e. pass file
>>> descriptions in as XML ?, use ISAM on Windows ?)
>>
>> 1. Automatically convert the VSAM (KSDS) Files to Relational Database
>> (Data Conversion - fully automated).
>>
>> 2. Load your existing VSAM data to the new table sets. (Load Module
>> generation and Loading - fully automated)
>>
>> That completes data conversion. Now you can access your DB with
>> standard software as well as COBOL. The report programs can be
>> systematically replaced with tools designed for reporting (Crystal
>> Reports, StimulSoft, etc.)... or not. Your choice. At least you have
>> some options... 3. Generate a Data Access Layer of Objects to access the
>> RDB table
>> sets. (DAL objects in OO COBOL that carry out all the access the
>> VSAM verbs used to.) These objects are generated from your RDB table
>> set definitions. This separates the data layer from the Business
>> logic without any real effort on your part. The objects are
>> multi-threaded and can be invoked easily from COBOL and any other
>> languages that support the Component Object Model. You can access
>> your new DB easily from new COBOL apps, Web Pages, or new apps
>> written in new languages, separately or conjointly. (fully automated)
>>
>> 4. Amend the application programs to replace all the VSAM access with
>> invokes of the DAL objects generated in 3 above. (over 95% automated
>> - some minor manual amendments in extreme cases, for very complex or
>> non-COBOL 85 compliant code.)
>>
>> At this point both Data and Code Conversion is complete. You have a
>> system that runs on the new networked platform under .NET, accesses
>> a relational database in a separate tier, and the existing
>> applications function exactly as they always have, except that now
>> they are accessing the new RDB instead of VSAM KSDS.
>>
>> (Although you CAN use ISAM under Windows as a VSAM equivalent,
>> Relational Databases are preferable because they are open,
>> standardised, and scalable.) Of course, if you can get them
>> automatically, without any manual effort, generated from your
>> exisiting COBOL copybooks, that is just another reason for going
>> that way. The Toolset generates normalised DB tables, along with
>> modules to load them, all from your existing legacy COBOL codebase,
>> in seconds. NEW applications can be developed on the Web or .NET using
>> COBOL or
>> whatever other languages you may want to use.
>>
>> If you are currently using CICS, you may want to replace this with
>> ASP.NET or WPF or simple WinForms. Fujitsu offer NeoKICKS, but this
>> DOES require the .NET COBOL compiler.
>>
>> The converted system runs under .NET using SQL Server or your RDBMS
>> of choice.
>>
>>>
>>> Any further comments or suggestions would be appreciated,
>>
>> Please see http://primacomputing.co.nz/cobol21/mig.aspx and
>> http://primacomputing.co.nz/cobol21/PRIMAToolset.aspx which describe
>> the background to the outline above.
>>
>> My personal opinion:
>>
>> It is fairly easy to "transfer" an existing COBOL system to a
>> different platform. (Whether that platform is networked
>> workstations or a new central processing site.) However doing this
>> simply takes time, money, and energy and provides no LONG TERM
>> relief. You might as well address conversion as a complete
>> Migration, and go for objects and layers which will see you well
>> into the future (as well as being much more viable in today's
>> networked environments.) Objects and layers allow you to use other
>> languages and tools besides COBOL. Re-factoring your existing code
>> means you can usually (not always...) save a good percentage of the
>> cost of rebuilding everything from scratch. I started moving off COBOL
>> around 4 years ago and encountered all the
>> problems described on the web site. I started writing tools to help
>> me, and since then have assisted other people to undertake the same
>> migration. Today I develop in C#, but I still have a number of
>> legacy COBOL components that are still doing the jobs they have
>> always done. As time and money permits, I'll gradually replace them,
>> but refactoring this functionality into objects has bought me time
>> and eased the transition into "New Technology".
>>
>> The PRIMA Toolset automatically creates objects and layers from
>> existing legacy code. I don't know any other conversion/migration
>> tools that do that.
>>
>> Good luck with whatever you decide.
>>
>> Pete.
>
> They want to do this where I work also. They call it re-hosting. The goal
> is to get everything off the mainframe by 09-30-20014. I
> was told that all of the work is being contracted out to MicroFocus.

It is a good choice. Micro Focus have good expertise in this area and are
committed to COBOL for the meantime.

> The main problem here is Datacomm DB which only runs on the mainframe
> and the Datacomm DB code is entwined within the program..

I remember accessing a Datacomm DB from a PC (as part of a demo of Fujitsu
COBOL under Windows) in the U.K. just before the Millennium... say 10 years
ago.

I was surprised there was an ODBC driver for it, but there was and it worked
fine.


> I think
> they will extract it by creating a data access layer. It will have
> to be replaced with a relational DB. I think they are going with
> Oracle.

That makes perfect sense to me. Objects and layers...
>
> I guess the replacement system development is taking too long and
> they want to save money on hardware and I believe they consider
> Datacomm DB to be expensive also.

I doubt that Oracle would be less expensive.


> There are plenty of horror stories
> about problems with the software developed so far for the replacement
> system. I will spare you the details for now.

Tell your Boss to contact me if it all goes pear-shaped :-)

Pete.

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


From: mainframezen on 26 Nov 2009 06:07
On Nov 24, 6:30 pm, Chuckles55 <chuckmoor...(a)gmail.com> wrote:
> Hi Everyone,
>
> My organization wants to move its IBM z/OS COBOL programs off onto
> another (perceived-to-be cheaper) platform. One option being discussed
> is converting the (400+) programs (most of which do financial
> crunching to create print files) to run on Windows using either
> MicroFocus COBOL or Fujitsu NETCOBOL. There will be 2-4 programmers on
> the conversion team.
> My questions:
> 1) Does anyone here have a preference between MicroFocus and Fujitsu ?
> 2) If anyone has done conversions like this, how were DD statement
> (let alone IDCAMS) functionality converted ? (i.e. pass file
> descriptions in as XML ?, use ISAM on Windows ?)

> Any further comments or suggestions would be appreciated,
> Chuck

It looks like a batch set of COBOL programs, maybe extracting data
from DB2 and reporting on files.

The first thing I recommend is a Pilot with Microfocus versus
Netcobol. A set of 5-10 COBOL programs the you can isolate and make a
PoC.
I know both and if you are strictly doing batch, both are equivalent.
Pricing can help to make a choice.

The second thing I recommend is using Linux. The NTFS filesystem is
slower and that you'll slow you down. Linux has fast and reliable
ext3. It works very well on my migration projects.

From the Linux box/farm you can talk directly with DB2 or do an ETL to
Oracle/DB2 on Linux.
You can do the crunching on ISAM like files.

JCL should be converted to Shell Script or some scripting language,
like Perl, Python, REXX, Ruby. I've done it and it's a great
environment for operations and developers.
The DD statements are converted to environment variables with the same
name as the SELECT ASSIGN descriptor. You must make it dynamic.
Then COBOL opens files specified by the contents of each (in case of
Microfocus I recommend prefixing with dd_) variable matching each
SELECT ASSIGN.
It can be a file name or a full path.

That's about it.




From: William M. Klein on 26 Nov 2009 18:57
Not, really disagreing with many of Pete's thoughts, but to give you some
more to "think about"

1) When considering "re-hosting" optionss, please do remember IBM's RDz
product (with "IBM COBOL for Windows" compiler). Rehositng isn't their
MAJOR target, but it can be used for such.

2) Comparing Micro Focus to Fujitsu (now Alchemy - and this is sort-of
significant), let me tell the most "important" issues to consider (from my
perspective)

- Micro Focus is ACTIVELY maintaining IBM compatibility. When IBM
introduces new features and syntax to Enterprise COBOL, MF usually has it
within "months" - certainly within a year or so. HOWEVER, as stated
elsewhere, MF does have "run-time fees". Depending on how many mahcines the
ported applicaitons will run on, this can be significant.

- Fujitsu doesn't even sell a Windows COBOL in the US anymore. (I think
they do in Japan - but not elsewhere in the world). The "sell off" to
Alchemy may or may not (in thelong run) be either good or bad for the
"future" of that compiler and environment. Hoeever, Fujitsu (and I think
Alchamey) have been VERY slow in doidng any "IBM COBOL compatibility" fixes
or enhancements in recent years. They don't have ANY IBM COBOL XML
support - and are missing many of the enhancements from the IBM compilers of
the last half decade or so. (If your mainframe COBOL uses "old" technology
only, this shouldn't be a problem - but if any of your programs use "new"
features, this will require lots of code changes and testing). HOWEVER,
they do have a free run-time and I don't expect this to change any time in
the future.

* * * * *

Micro Focus has *full* JCL support (including utilities like IDCAMS). For
the short term, this means that you need to spend ZERO effort in doing
"environment" migrations. I think (but am not certain) that Fujitsu had
SOME JCL suppoert. Again, I don't think thery are maintaining andenhancing
this support. ON THE OTHER HAND, for the long run, it is "best" if you are
migrating your applications to Windows to (some time) migerate the
"environment" tools as well.

For both Micro Focusand Alchamy (aka Fujitsu), their "flagship" products
(today) for Windows are ".NET" targeted. On the other hand, BOTH vendors do
offer (sell) products that are .NET independent. When talking to sales
people, make certain that you make it clear which you want.

One other advantage (for some z/OS shops) of Micro Focus is that they also
have bothe Assembler and PL/I products/features. If you, like many shops,
have ANY assembler subroutines used by your applications, the MF soltuion
will defintely be an easier migration path. Last I checked MF was still
"working on" mixed COBOL-PL/I support, but this is USUALY less of an issue.
If it is important to you,check with MF.

"Chuckles55" <chuckmoore55(a)gmail.com> wrote in message
news:89888226-4792-45d5-b19b-c304f94250c1(a)v15g2000prn.googlegroups.com...
> Hi Everyone,
>
> My organization wants to move its IBM z/OS COBOL programs off onto
> another (perceived-to-be cheaper) platform. One option being discussed
> is converting the (400+) programs (most of which do financial
> crunching to create print files) to run on Windows using either
> MicroFocus COBOL or Fujitsu NETCOBOL. There will be 2-4 programmers on
> the conversion team.
> My questions:
> 1) Does anyone here have a preference between MicroFocus and Fujitsu ?
> 2) If anyone has done conversions like this, how were DD statement
> (let alone IDCAMS) functionality converted ? (i.e. pass file
> descriptions in as XML ?, use ISAM on Windows ?)
>
> Any further comments or suggestions would be appreciated,
> Chuck


From: Cláudio Miguel Müller on 27 Nov 2009 11:22
On Nov 24, 3:30 pm, Chuckles55 <chuckmoor...(a)gmail.com> wrote:
> Hi Everyone,
>
> My organization wants to move its IBM z/OS COBOL programs off onto
> another (perceived-to-be cheaper) platform. One option being discussed
> is converting the (400+) programs (most of which do financial
> crunching to create print files) to run on Windows using either
> MicroFocus COBOL or Fujitsu NETCOBOL. There will be 2-4 programmers on
> the conversion team.
> My questions:
> 1) Does anyone here have a preference between MicroFocus and Fujitsu ?
> 2) If anyone has done conversions like this, how were DD statement
> (let alone IDCAMS) functionality converted ? (i.e. pass file
> descriptions in as XML ?, use ISAM on Windows ?)
>
> Any further comments or suggestions would be appreciated,
> Chuck

Hello Chuck,
I saw your message in this forum, I have a suggestion.
See software FILES2SQL in www.cobol.com.ar/files2sql,
100% Compatible with Microfocus Cobol.
It makes file conversion to Cobol Databases. Very useful and
practical.
I hope that helps you to do this.

Cláudio Muller
Brazil
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: "Hello World" OpenCobol query
Next: "Climategate" code