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=A0am, "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 (Da=
ta
> 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 use=
d
> to.) These objects are generated from your RDB table set definitions. Thi=
s
> 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. Yo=
u
> 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 - so=
me
> minor manual amendments in extreme cases, for very complex or non-COBOL 8=
5
> 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=A0pm, 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=A0pm, 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=A0pm, 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=E1udio 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

On Tue, 24 Nov 2009 10:30:04 -0800 (PST), Chuckles55
<chuckmoore55@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 ?)

Have the powers that be checked on the deal of the week from IBM to
see if they can reduce costs?  Since RDz supports COBOL, there is the
possibility of moving into a development environment that might have
data dictionaries and repository support.  The general management
mentality in all too many cases has been to actively ignore advances
made in the COBOL environment and z series operating systems.  I have
serious doubts about the long term future of both COBOL and the z
series but in many cases management is not taking advantage of the
readily available tools (including Java) that are on the mainframe.
Reading about managements that refuse to upgrade from COBOL 74 makes
me wonder about their competence.
>
>Any further comments or suggestions would be appreciated,
>Chuck

On Nov 27, 11:22=A0am, Cl=E1udio Miguel M=FCller
<claudiomiguelmul...@gmail.com> wrote:
> On Nov 24, 3:30=A0pm, 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 inwww.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=E1udio Muller
> Brazil


ERROR NOT FOUND 404
AT
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=E1udio Muller
Brazil

On Nov 27, 1:22=A0pm, Cl=E1udio Miguel M=FCller
<claudiomiguelmul...@gmail.com> wrote:
> On Nov 24, 3:30=A0pm, 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 inwww.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=E1udio Muller
> Brazil

AT
Hello Chuck,
new LINK ...
I saw your message in this forum, I have a suggestion.
See software FILES2SQL in http://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=E1udio Muller
Brazil

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

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

On 2010-01-04 13:19:35 -0600, Chuckles55 <chuckmoore55@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

On Mon, 4 Jan 2010 11:19:35 -0800 (PST), Chuckles55
<chuckmoore55@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

On Tue, 5 Jan 2010 10:56:57 +1300, "Pete Dashwood"
<dashwood@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.

Clark F Morris wrote:
> On Tue, 5 Jan 2010 10:56:57 +1300, "Pete Dashwood"
> <dashwood@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.

I hadn't thought about it like that, but I'm sure you are right, Clark.

I guess it takes education and persuasion. Pilot projects can be good.

But really, it needs a ground swell of opinion at all levels. That only 
comes from recognising the need for change and trying some new approaches.

Once you can actually SEE benefits it is hard to argue against.

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

In article <7qgmuhFc2vU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>Clark F Morris wrote:

[snip]

>> 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.
>
>I hadn't thought about it like that, but I'm sure you are right, Clark.
>
>I guess it takes education and persuasion. Pilot projects can be good.

Education costs MONEY, Mr Dashwood, and gives employees that horrible 
impression that 'I can learn something new so I must be Worth More Pay 
than someone who can't'... and pilot projects cost MONEY, as well.  What 
Manager worth the next quarter's bottom-line would dare spend MONEY on 
something that might not work?  A few decades ago the buzz-phrase was 'We 
Get It Right The First Time'; an experiment, by definition, does not have 
a predictable result.

>
>But really, it needs a ground swell of opinion at all levels.

One of the current buzz-phrases is 'Times Are Hard'; if it was difficult 
to get someone to spend MONEY when the Times Were Good then I doubt that 
it is going to be easier now.

DD

docdwarf@panix.com wrote:
> In article <7qgmuhFc2vU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>> Clark F Morris wrote:
>
> [snip]
>
>>> 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.
>>
>> I hadn't thought about it like that, but I'm sure you are right,
>> Clark.
>>
>> I guess it takes education and persuasion. Pilot projects can be
>> good.
>
> Education costs MONEY, Mr Dashwood, and gives employees that horrible
> impression that 'I can learn something new so I must be Worth More Pay
> than someone who can't'... and pilot projects cost MONEY, as well.
> What Manager worth the next quarter's bottom-line would dare spend
> MONEY on something that might not work?  A few decades ago the
> buzz-phrase was 'We Get It Right The First Time'; an experiment, by
> definition, does not have a predictable result.
>
>>
>> But really, it needs a ground swell of opinion at all levels.
>
> One of the current buzz-phrases is 'Times Are Hard'; if it was
> difficult to get someone to spend MONEY when the Times Were Good then
> I doubt that it is going to be easier now.
>
> DD

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

docdwarf@panix.com wrote:
> In article <7qgmuhFc2vU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>> Clark F Morris wrote:
>
> [snip]
>
>>> 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.
>>
>> I hadn't thought about it like that, but I'm sure you are right,
>> Clark.
>>
>> I guess it takes education and persuasion. Pilot projects can be
>> good.
>
> Education costs MONEY, Mr Dashwood, and gives employees that horrible
> impression that 'I can learn something new so I must be Worth More Pay
> than someone who can't'... and pilot projects cost MONEY, as well.
> What Manager worth the next quarter's bottom-line would dare spend
> MONEY on something that might not work?  A few decades ago the
> buzz-phrase was 'We Get It Right The First Time'; an experiment, by
> definition, does not have a predictable result.

I think it is the perception of MONEY that matters, Doc.

There's plenty of MONEY for people to fly to conferences and meetings in 
private corporate jets, for example...

Trying to expand a small business as I currently am, I do appreciate that 
MONEY is important. Nevertheless, I make sure that a percentage of our 
meagre funds is re-invested back into the business. This year, clients 
received a holiday pack from PRIMA just to let them know they are 
appreciated. (It's the first time we've been able to afford to do that and 
it is a really good feeling... :-))

Personally, I won't hesitate to spend MONEY as long as I know we can afford 
it and as long as there is a fighting chance it will return to us at some 
point. Investment in improving products and services, and training people is 
really a no brainer. I don't have a large enough client base yet to warrant 
full time employees but if/when we reach that point, I'll be happy to get 
some and ensure they are trained.

I've had conversations with Senior Managers (particularly in the U.K.) where 
they worry that they can spend thousands training someone, and then said 
"someone" will flit off to a competitor. I pointed out that if they don't 
value the training then that is inevitable. (Why spend large sums of money 
on courses if the result has no added value?). If the training is valuable, 
then recognise that. You should be valuing your employees anyway (why would 
you employ people who are of no value to you?), and pay them accordingly. Of 
course, "good business" dictates getting as much value as you can for as 
little MONEY  as possible, and that is the perceived wisdom of most 
managers. But just HOW "good" is that model? It certainly isn't good long 
term, when you have a company full of demotivated, undervalued, discouraged 
employees who hate turning up for work in the morning and are there because 
of family responsibility or apathy or until they can get a better offer (and 
they won't get a better offer because when they go for an interview there is 
a smell of despair about them that communicates to a prospective 
employer...). You can hardly expect such a work force to achieve its true 
potential... For myself, I think life is too short to work in a miserable 
company, for small minded people who wallow in their own meanness. As a taxi 
driver in Sri Lanka once told me: "I have two arms, I have two legs, I can 
make a living."

If the company simply doesn't have the MONEY and can't afford to pay the 
staff what they're worth, that is a different case. Hopefully, that is a 
temporary condition and future cash flow will rectify it. My experience is 
that it pays to be open and up front with the people who are working for 
you. If there is a cash flow problem, tell them, and explain what you are 
doing to deal with it.  Honesty tends to beget loyalty; people like working 
for someone they can trust. And loyalty is an asset beyond rubies.

>
>>
>> But really, it needs a ground swell of opinion at all levels.
>
> One of the current buzz-phrases is 'Times Are Hard'; if it was
> difficult to get someone to spend MONEY when the Times Were Good then
> I doubt that it is going to be easier now.

Definitely not, if you buy in to the "Times Are Hard" bullshit.

Hard work is always hard, irrespective of the "times". Certainly, there are 
times when MONEY is more plentiful than other times, but getting people to 
part with it has never been "easy" (unless you are offering something 
illegal or in high demand, or which the buyer considers essential for life).

How "hard" are the times when someone can stand outside a football (or other 
major sports or entertainment) stadium and sell tickets for 20 - 50 times 
the price printed on them?  The 1930s were "hard" times; our "recession" is 
not even in the same league.

(It is quite amazing how travel tends to change your perspective on things. 
I always considered our neighbourhood, including our family and our friends 
and neighbours, to be "poor" when I was growing up. I started to understand 
what "poor" really means when I saw a family living in a packing case and 
watching distraugt and helpless as one of their children died of starvation, 
in Bangla Desh.)

I was in Melbourne about the time the "recession" was officially announced. 
A friend of mine told me that his wife had been parked across the road from 
a BMW franchise and there was a steady stream of new cars being purchased 
and driven away.

So it isn't really MONEY that is the problem; it is how we deal with MONEY, 
and our perception of it.

A very wise friend of mine (now sadly departed this life) used to say: 
"Being 'broke' is a state of mind; having no MONEY is a temporary 
condition."

He was right.

MONEY needs to flow and get passed around. If you try and hang on to it, you 
break the flow and suffer the consequences.

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

On Jan 6, 12:58=A0am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> docdw...@panix.com wrote:
> I've had conversations with Senior Managers (particularly in the U.K.) wh=
ere
> they worry that they can spend thousands training someone, and then said
> "someone" will flit off to a competitor.

Flitting off has always been a response to completing a training
course. There are two ways to making it difficult for an employee to
grab training and running:

1.  Make their workplace such an enjoyable environment such that they
are too contented to look elsewhere. Unfortunately, mangement and
their organizations are too tied in to the protestant work ethic to
consider this as a viable option.

2.  Require the trainee to re-imburse the company for a proportion of
the training depending upon how long after they receive training
before they leave. (As per EDS).

In my experience, only one person I know of (in 30 years of IT work)
left shortly after receiving training (he was no good at Cobol CICS
programming or anything else for that matter).

Sometimes managers are too in to their narrow viewpoints to recognise
the reality of how awful their workplace can be. I remember the quip
from one manager who said that "it was not true that people were
leaving in droves" (after half of the IT department had walked in the
previous 12 months).

On Wed, 6 Jan 2010 13:58:47 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Personally, I won't hesitate to spend MONEY as long as I know we can afford 
>it and as long as there is a fighting chance it will return to us at some 
>point.

Too many decision makers are concerned way too strongly with short
term results of their decisions.    Some get their promotion or bonus
then find another job.   Some "do something" about the current issue
and get reelected.

Way too often this is at the cost of the long term results.

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

On Wed, 6 Jan 2010 06:33:40 -0800 (PST), Alistair
<alistair@ld50macca.demon.co.uk> wrote:

>Sometimes managers are too in to their narrow viewpoints to recognise
>the reality of how awful their workplace can be. I remember the quip
>from one manager who said that "it was not true that people were
>leaving in droves" (after half of the IT department had walked in the
>previous 12 months).

I read this shortly after reading how the coach of the Denver Broncos
described his team.     People say if you think pro athletes are prima
donnas, it's because we haven't spent time upstairs - the coaches and
owners make them look like regular guys.

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

In article <7qi5i8F42uU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>docdwarf@panix.com wrote:
>> In article <7qgmuhFc2vU1@mid.individual.net>,
>> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>>> Clark F Morris wrote:
>>
>> [snip]
>>
>>>> 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.
>>>
>>> I hadn't thought about it like that, but I'm sure you are right,
>>> Clark.
>>>
>>> I guess it takes education and persuasion. Pilot projects can be
>>> good.
>>
>> Education costs MONEY, Mr Dashwood, and gives employees that horrible
>> impression that 'I can learn something new so I must be Worth More Pay
>> than someone who can't'... and pilot projects cost MONEY, as well.
>> What Manager worth the next quarter's bottom-line would dare spend
>> MONEY on something that might not work?  A few decades ago the
>> buzz-phrase was 'We Get It Right The First Time'; an experiment, by
>> definition, does not have a predictable result.
>
>I think it is the perception of MONEY that matters, Doc.

Some think that everything is a matter of perception, Mr Dashwood, down to 
a condition they call 'existence'; I seem to recall something about that 
('esse est percipi')  from the works of Bishop Berkely I read long ago.

>
>There's plenty of MONEY for people to fly to conferences and meetings in 
>private corporate jets, for example...
>
>Trying to expand a small business as I currently am, I do appreciate that 
>MONEY is important.

Trying to expand a small business might, possibly, be quantitatively and 
qualitatively differ from existing and thriving in a Fortune 100 
corporation.

DD