IBM COBOL Migration to Windows COBOL
in [Cobol]
|
Prev: "Hello World" OpenCobol query
Next: "Climategate" code
From: Chuckles55 on 24 Nov 2009 13:30 Hi Everyone, My organization wants to move its IBM z/OS COBOL programs off onto another (perceived-to-be cheaper) platform. One option being discussed is converting the (400+) programs (most of which do financial crunching to create print files) to run on Windows using either MicroFocus COBOL or Fujitsu NETCOBOL. There will be 2-4 programmers on the conversion team. My questions: 1) Does anyone here have a preference between MicroFocus and Fujitsu ? 2) If anyone has done conversions like this, how were DD statement (let alone IDCAMS) functionality converted ? (i.e. pass file descriptions in as XML ?, use ISAM on Windows ?) Any further comments or suggestions would be appreciated, Chuck
From: Pete Dashwood on 25 Nov 2009 06:48 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."
From: Mark on 25 Nov 2009 08:14 On Nov 25, 5:48 am, "Pete Dashwood" <dashw...(a)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
From: Pete Dashwood on 25 Nov 2009 10:22 Mark wrote: > On Nov 25, 5:48 am, "Pete Dashwood" > <dashw...(a)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."
From: B-Riemke on 25 Nov 2009 12:22
On Nov 24, 7:30 pm, Chuckles55 <chuckmoor...(a)gmail.com> wrote: > Hi Everyone, > > My organization wants to move its IBM z/OS COBOL programs off onto > another (perceived-to-be cheaper) platform. One option being discussed > is converting the (400+) programs (most of which do financial > crunching to create print files) to run on Windows using either > MicroFocus COBOL or Fujitsu NETCOBOL. There will be 2-4 programmers on > the conversion team. > My questions: > 1) Does anyone here have a preference between MicroFocus and Fujitsu ? > 2) If anyone has done conversions like this, how were DD statement > (let alone IDCAMS) functionality converted ? (i.e. pass file > descriptions in as XML ?, use ISAM on Windows ?) > > Any further comments or suggestions would be appreciated, > Chuck 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 |