IBM COBOL Migration to Windows COBOL

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

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.

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

On Nov 25, 5:48*am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> 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.)

Pete, what are your methods for converting batch applications and JCL
specifically?

-Bob

Mark wrote:
> On Nov 25, 5:48 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>> 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.)
>
> Pete, what are your methods for converting batch applications and JCL
> specifically?
>
> -Bob

Batch applications use DAL the same as everything else. The current VSAM
verbs (START, READ NEXT, etc) are replaced with invokes of DAL objects,
automatically by a process we call "transformation". Transformation
automatically ensures that the existing non-OO Batch COBOL invokes the right
methods of the right DAL objects to replace the previous indexed file
access. The interface to these objects is through the same record
definition that was used for the VSAM files. (The DAL objects get and put
data between these buffers and the RDB table set, doing validations and type
conversions and handling threading, object instantiation, DB connection, and
control information and status.) The output from transformation gets
recompiled and then runs on the new platform, against the new database.

Performance will probably be marginally slower for a single thread than it
was on the old platform against indexed files. However, the difference is
seldom noticeable and if it becomes problematic it is a simple matter to set
more threads running, or run more servers. Very large volumes need special
consideration and design. Because of the tier separation, it is usually
possible to physically tune and "rearrange" the table sets without having
any impact on the applications. A good DBA can identify and nullify
bottlenecks very quickly.

JCL for z/OS we have never done (yet...) but JCL for other platforms has
been replaced by Windows scripting. If you remove the flat files it reduces
the JCL correspondingly. I don't see it as being problematic.

Obviously, we would need to look at what was specifically required for that
environment and, as I don't currently have access to that environment (I can
get it...) I haven't tried very hard to get IBM sites using the Toolset. (I
worked with IBM mainframes for many years and am familiar with JCL, but a
lot of what is necessary in that environment, isn't under Windows. File
allocation, IDCAMS, dummy steps like IEBGENER, are all academic, for
example. Conditional return from job steps is easily handled with scripting.

If and when we undertake a mainframe Migration, I would be working very
closely with the client to address any problems specific to that environment
which we haven't encountered elsewhere. (I'm fairly confident there wouldn't
be many... :-))

My personal approach to Batch Processing is to remove the need for it, but
that is another story... :-)

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

On Nov 24, 7:30*pm, Chuckles55 <chuckmoor...@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

Hi Chuck,

where did you come from?

I made this job with many more thinks by Micro Focus... (i worked
there for many years)

What is you real E-Mail adress?

Best regards

Bernd

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:7n4jriF3jqndeU1@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.

Charles Hottel wrote:
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:7n4jriF3jqndeU1@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."

On Nov 24, 6:30*pm, Chuckles55 <chuckmoor...@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.

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@gmail.com> wrote in message
news:89888226-4792-45d5-b19b-c304f94250c1@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

William M. Klein wrote:
> Not, really disagreing with many of Pete's thoughts, but to give you
> some more to "think about"

I guess it comes down to whether you simply want to "re-host" or whether you
want to refactor for a completely different future.

I'm obviously in favour of the latter because that is the route I've gone
and I built tools to assist with going that route.

For me, I see no long term future in COBOL and it is advisable to open up
the options and allow other things to be added to the mix. That pretty much
means "objects and layers", so that has been the position I consistently
support. I see no need to discard COBOL code that is currently working
without problem, but I do want a slice of the new technology cake as well. I
see it as being about options, and locking yourself in to COBOL simply
closes those options down.

However, I readily admit this is an arguable position and many people will
not agree with it.

There are many sites that are not ready to let go of COBOL just yet and
moving it to a cheaper platform may be a viable option.

I guess my argument is that if you are going to expend time, energy, and
money doing that, then why not go all the way and move into the 21st
century? But, like I said, it is arguable. People who have not experienced
the advantages of objects and separation layers, will not be persuaded. All
I would say is that a move to such an environment is INEVITABLE in the long
term. It's not a question of IF, it is a question of WHEN...

Doing it sooner rather than later has a number of advantages:

1. It buys you time to manage and modernise the existing COBOL resources
(people and software).
2. It gives immediate advantage in opening up the data resource to standard
tools. (No more ad hoc COBOL reports...)
3. It motivates the team to see they are going somewhere, rather than just
the "same old same old" on a new platform.
4. It gives immediate access to Web Based development and use of the
existing data resource. (Yes, you CAN run COBOL CGI and ISAPI and access
ISAM data, but there is NO COMPARISON to using ASP.NET, server side
code-behinds,and reusing the SAME DAL objects that are used with your
desktop applications...)

Having declared my bias, I'll make a few further comments below... :-)

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

And what you get is COBOL under Windows... (same old same old...)
>
> 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.

But if you're planning on moving away from the IBM platform, why would you
care?

This is just about mindset and force of habit.

If you are intending to maintain the SAME level of commitment to COBOL on
the new platform that you did for the last few decades on the old one, THEN
you might care. (Is anybody who is migrating REALLY intending to do that?)



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.

For me that was a show stopper. Not because I'm running dozens or hundreds
of workstations, but because I'm developing software and I simply can't add
a Micro Focus RT fee to every unit I sell.



>
> - 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 way I heard it was that they were having trouble supporting win 7 and
were working on it. I haven't visited the Alchemy site recently and the
information is via a third party. Unfortunately "support" is still not a
strong point for Alchemy (judging by some stuff I received in private mail
yesterday.)



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

I don't think it really matters, Bill. There is a question over ALL
implementations of COBOL as a long term leading development tool...
irrespective of who supplies it.


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

XML support is easily implemented under Windows, using ANY version of COBOL
that compiles in that environment. It was never necessary to have XML
support included in the language and it was probably not a good move as the
XML standard itself is still in flux. It makes more sense to use an external
XML handling facility (as provided with Windows). I would be very surprised
if anyone makes a fuss about their COBOL XML needing to be tweaked because
they are migrating.


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

A very good point, Bill. From what I'm seeing (admittedly not IBM mainframe
sites) most of the legacy IS old COBOL (some of it is VERY old; we're
currently dealing with stuff written before the '85 standard... :-))
>
> * * * * *
>
> Micro Focus has *full* JCL support (including utilities like IDCAMS).

Again, this comes down to mindset. If you're not using VSAM, you don't need
IDCAMS... let it go... :-)


> For the short term, this means that you need to spend ZERO effort in
> doing "environment" migrations.

Sure. I guess we diverge on whether an "environment" migration is worth the
effort...

I don't really disagree with you, Bill. There are many people who will find
this attractive. I just believe it is not enough... :-)

As you have qualified it with "short term" I find myself less resistant. For
a short term solution it could well be viable, I guess.



I think (but am not certain) that
> Fujitsu had SOME JCL suppoert.

As far as I know, they don't. But, in their defience, it shouldn't really be
necessary anyway...

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

I think the idea is to grasp the new paradigm. You only need the old tools
if you cling to the old ways. The fact is that the new tools are so much
more powerful you will find yourself using them in preference (that was my
experience with Visual Studio - all strange at first, but once you get round
the learning curve (and, for me, video self instruction accellerated this
process) there is no comparison. There is no comparison between using ISPF
and IntelliSense in VS 2008. After a month or so, you wonder how you ever
got by without it...


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

Another very good point, Bill. It is very easy to be persuaded you can't
migrate without a .NET COBOL compiler. You certainly can. If you are
planning to move away from COBOL it would be foolish in the extreme to
"invest" in something you won't use and don't need. Want to develop new
stuff for .NET? Use C#. It's free and it can run with your existing COBOL
apps as long as they are wrapped as objects. (That "wrapping" can be
automated...)


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

Very useful for an "Environment migration". But shouldn't we be trying to
get away from dependence on Assembler routines?

<snipped original post>
Pete.
--
"I used to write COBOL...now I can do anything."

On Nov 24, 3:30*pm, Chuckles55 <chuckmoor...@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

Pete,
I think we (sort-of) agree that the first decision that needs to be made
is what is the intention of the migration:

- Is it to simply "move" tyheapplication ofgf the mainframe and keep it "as
much like it was" as possible
or
- I the intent to move the application into "the modern world" so that it
is easy to maintain eand enhance with "Windows" personael and resources.

There are< I think PROs and CONs for both and this decision "up front" will
impact how such a migration should be made. It is my perceptions (and I
could be right or wrong) that you don't see many (if any) PROs to doing a
"rehosting" of a mainframe application to Windows - without ALSO doing a
"migration" to "newer technology".

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:7n9qsrF3k440bU1@mid.individual.net...
> William M. Klein wrote:
>> Not, really disagreing with many of Pete's thoughts, but to give you
>> some more to "think about"
>
> I guess it comes down to whether you simply want to "re-host" or whether
> you want to refactor for a completely different future.
>
> I'm obviously in favour of the latter because that is the route I've gone
> and I built tools to assist with going that route.
>
> For me, I see no long term future in COBOL and it is advisable to open up
> the options and allow other things to be added to the mix. That pretty
> much means "objects and layers", so that has been the position I
> consistently support. I see no need to discard COBOL code that is
> currently working without problem, but I do want a slice of the new
> technology cake as well. I see it as being about options, and locking
> yourself in to COBOL simply closes those options down.
>
> However, I readily admit this is an arguable position and many people will
> not agree with it.
>
> There are many sites that are not ready to let go of COBOL just yet and
> moving it to a cheaper platform may be a viable option.
>
> I guess my argument is that if you are going to expend time, energy, and
> money doing that, then why not go all the way and move into the 21st
> century? But, like I said, it is arguable. People who have not experienced
> the advantages of objects and separation layers, will not be persuaded.
> All I would say is that a move to such an environment is INEVITABLE in the
> long term. It's not a question of IF, it is a question of WHEN...
>
> Doing it sooner rather than later has a number of advantages:
>
> 1. It buys you time to manage and modernise the existing COBOL resources
> (people and software).
> 2. It gives immediate advantage in opening up the data resource to
> standard tools. (No more ad hoc COBOL reports...)
> 3. It motivates the team to see they are going somewhere, rather than just
> the "same old same old" on a new platform.
> 4. It gives immediate access to Web Based development and use of the
> existing data resource. (Yes, you CAN run COBOL CGI and ISAPI and access
> ISAM data, but there is NO COMPARISON to using ASP.NET, server side
> code-behinds,and reusing the SAME DAL objects that are used with your
> desktop applications...)
>
> Having declared my bias, I'll make a few further comments below... :-)
>
>>
>> 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.
>
> And what you get is COBOL under Windows... (same old same old...)
>>
>> 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.
>
> But if you're planning on moving away from the IBM platform, why would you
> care?
>
> This is just about mindset and force of habit.
>
> If you are intending to maintain the SAME level of commitment to COBOL on
> the new platform that you did for the last few decades on the old one,
> THEN you might care. (Is anybody who is migrating REALLY intending to do
> that?)
>
>
>
> 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.
>
> For me that was a show stopper. Not because I'm running dozens or hundreds
> of workstations, but because I'm developing software and I simply can't
> add a Micro Focus RT fee to every unit I sell.
>
>
>
>>
>> - 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 way I heard it was that they were having trouble supporting win 7 and
> were working on it. I haven't visited the Alchemy site recently and the
> information is via a third party. Unfortunately "support" is still not a
> strong point for Alchemy (judging by some stuff I received in private mail
> yesterday.)
>
>
>
>> 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.
>
> I don't think it really matters, Bill. There is a question over ALL
> implementations of COBOL as a long term leading development tool...
> irrespective of who supplies it.
>
>
>> 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.
>
> XML support is easily implemented under Windows, using ANY version of
> COBOL that compiles in that environment. It was never necessary to have
> XML support included in the language and it was probably not a good move
> as the XML standard itself is still in flux. It makes more sense to use an
> external XML handling facility (as provided with Windows). I would be very
> surprised if anyone makes a fuss about their COBOL XML needing to be
> tweaked because they are migrating.
>
>
>> (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.
>
> A very good point, Bill. From what I'm seeing (admittedly not IBM
> mainframe sites) most of the legacy IS old COBOL (some of it is VERY old;
> we're currently dealing with stuff written before the '85 standard... :-))
>>
>> * * * * *
>>
>> Micro Focus has *full* JCL support (including utilities like IDCAMS).
>
> Again, this comes down to mindset. If you're not using VSAM, you don't
> need IDCAMS... let it go... :-)
>
>
>> For the short term, this means that you need to spend ZERO effort in
>> doing "environment" migrations.
>
> Sure. I guess we diverge on whether an "environment" migration is worth
> the effort...
>
> I don't really disagree with you, Bill. There are many people who will
> find this attractive. I just believe it is not enough... :-)
>
> As you have qualified it with "short term" I find myself less resistant.
> For a short term solution it could well be viable, I guess.
>
>
>
> I think (but am not certain) that
>> Fujitsu had SOME JCL suppoert.
>
> As far as I know, they don't. But, in their defience, it shouldn't really
> be necessary anyway...
>
>>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.
>
> I think the idea is to grasp the new paradigm. You only need the old tools
> if you cling to the old ways. The fact is that the new tools are so much
> more powerful you will find yourself using them in preference (that was
> my experience with Visual Studio - all strange at first, but once you get
> round the learning curve (and, for me, video self instruction accellerated
> this process) there is no comparison. There is no comparison between using
> ISPF and IntelliSense in VS 2008. After a month or so, you wonder how you
> ever got by without it...
>
>
>>
>> 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.
>
> Another very good point, Bill. It is very easy to be persuaded you can't
> migrate without a .NET COBOL compiler. You certainly can. If you are
> planning to move away from COBOL it would be foolish in the extreme to
> "invest" in something you won't use and don't need. Want to develop new
> stuff for .NET? Use C#. It's free and it can run with your existing COBOL
> apps as long as they are wrapped as objects. (That "wrapping" can be
> automated...)
>
>
>>
>> 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.
>
> Very useful for an "Environment migration". But shouldn't we be trying to
> get away from dependence on Assembler routines?
>
> <snipped original post>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
>

William M. Klein wrote:
> Pete,
> I think we (sort-of) agree that the first decision that needs to be
> made is what is the intention of the migration:

Yes. Absolutely.

(In fact, I find myself in "general agreement" with your position; I'd just
like it to go further :-))
>
> - Is it to simply "move" tyheapplication ofgf the mainframe and keep
> it "as much like it was" as possible
> or
> - I the intent to move the application into "the modern world" so
> that it is easy to maintain eand enhance with "Windows" personael and
> resources.

I'm not sure it is as black-and-white as that, but, in principle, yes.
>
> There are< I think PROs and CONs for both and this decision "up
> front" will impact how such a migration should be made. It is my
> perceptions (and I could be right or wrong) that you don't see many
> (if any) PROs to doing a "rehosting" of a mainframe application to
> Windows - without ALSO doing a "migration" to "newer technology".

Yes, I think I said as much... :-)

However, I have stressed all along that this is an arguable personal
opinion. I have listened to opposing arguments from yourself and others and
I am sure that for some sites, this is valid and viable, particularly as a
"short term" measure that gets them off a particular platform. It's kind of
like a "Staging Post" that means they can keep what they have and "have a
look around" before making any drastic decisions. I understand the position,
I just don't agree with it.

The way I see this is that an opportunity is lost, and the overall migration
costs are increased.

That opinion is predicated on the belief that COBOL will not be viable (on
ANY platform...) into the long term future.

That means that migration is inevitable some time. (Unless you pack in your
IT or outsource it totally...)

There is therefore a golden opportunity to get rid of your indexed flat
files and procedural processing, and move into a world of objects and layers
that can be automatically generated as you migrate. If you DON'T do that
when you migrate it is harder (and more expensive) to do it later. (It is
still "doable" but it means repeating quite a bit of "stuff" you had to do
to get to the new platform, and that just seems wasteful to me.)

Unfortunately, most of the popular Migration efforts don't seem to be
concerned about what happens after you are on the new platform. They are
encouraging "same old same old" because their businesses are focused around
COBOL. It is a short term tactic, rather than a long term strategy.

For me, it isn't about perpetuating COBOL (my clients can stay with COBOL or
move to something else, or mix the two without problem; I really don't
care - I have no vested interest in what they use), it is about ensuring
that people moving to a new platform are able to lever the very best out of
that platform. That means objects and layers. This is a pretty hefty mindset
change for sites that have traditionally only used COBOL and time and
training are needed to make the necessary adjustments. BUT these adjustments
are worth it. (I know because I had to make them myself...)

Moving off the current platform is a golden opportunity to embrace the new
technology fully and open up non-COBOL options.

But that doesn't mean I think migrating to a new platform and NOT changing
is "wrong". :-)

It depends on the people, the circumstances, the size of the company, and
the corporate culture, just as much as on the technical and fiscal drivers.

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

On Sun, 29 Nov 2009 23:25:24 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>There is therefore a golden opportunity to get rid of your indexed flat
>files and procedural processing, and move into a world of objects and layers
>that can be automatically generated as you migrate. If you DON'T do that
>when you migrate it is harder (and more expensive) to do it later. (It is
>still "doable" but it means repeating quite a bit of "stuff" you had to do
>to get to the new platform, and that just seems wasteful to me.)

We pretty much have already gotten rid of indexed flat files and
replaced them with the black boxes of databases. But it's just a
different degree of layering from what we had before without moving to
objects.

Still, when moving to a new system, as always (in my experience), we
find that not all of the old data quite fit the new business model. No
amount of encapsulating will make them fit right.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison

Everyone,

Thanks very much for the comments !

I'll soon be having a discussion with management regarding the top one
or two options for transferring our organization's z/OS batch jobs to
something-else. Your comments, along with the results of investigation
into sister-organizations' experiences in COBOL-to-COBOL/C#/etc., will
help the management discussion.

Thanks again,
Chuck