As you may be aware, IBM is withdrawing support for CSP on 12/31/2001. This presents CSP customers with some difficult decisions:

• Do nothing!

• Replace Project(s)

• Migrate CSP to VisualAge Generator

• Port Project(s) to another language, such as COBOL

• Some combination of the above

 This document discusses each of these options.

Do Nothing!

At first glance this appears to be the easiest choice, but upon further examination a number of factors need to be considered

• Is unsupported code acceptable to the organization / auditors?

• Although unsupported, you will still have to pay CSP license fees

• How stable is your CSP Project(s)? Is it frozen, or is there on-going maintenance?  

• How critical to the business is the CSP Project(s)?

• Even if the CSP code is stable, remember any changes to the Operating System, CICS, COBOL, DB2, etc. could potentially cause a problem for the CSP code.

 Replace Project(s)

• Purchase Package  

• Re-write

• Eliminate

The first two options will probably be too expensive and time-consuming and the third option is unlikely in most cases.

We do offer an alternative to an expensive rewrite of a project with our BW*Wizard code generator. We can build new systems very rapidly and cheaply.  If you have systems that are largely table-maintenance in function, it may be counter-intuitive, but this is actually the best and least expensive option available.  For example, if you send us the 'create table' SQL/DDL for a couple of tables, in a couple of hours we can build list and maintenance programs for these tables, ready to be tested, with well-structured, error-free code that looks like the very best hand-written code.  Even if you have extensive business logic, replacing an old, hard to maintain system with a new well-structured one can be a powerful incentive to move in this direction, especially when the cost is reasonable.  For some companies, the idea of moving to a web browser interface with Java servlets can push them in this direction, and BW*Wizard even offers an option to build CICS COBOL programs which are called from the Java servlets to do all the SQL or VSAM database I/O, allowing business logic to remain in COBOL, where the developers may have more skills.

This can be the simplest migration option that will result in supported code. It is also likely to be the lowest cost conversion option, at least in the short-term. Only very trivial syntax changes will be required and they will be handled automatically on importing into VA Generator. If you have experienced CSP developers they will not have to learn a “new language”.

• CSP source code is held in VSAM files called MSLs, which can be concatenated

• VA Generator source code is held in an ‘ENVY’ repository on a PC LAN, grouped into ‘Packages’ or ‘Applications’ (not to be confused  with CSP applications, which are now called programs)    

• CSP Development and testing is performed with 3270 terminals, in TSO or CICS

• VA Generator Development and testing is performed with powerful PCs on a high-speed LAN

• CSP programs are compiled directly from MSLs using JCL

• VA Generator program source code is generated on each developer’s PC or a shared Server, then uploaded to TSO and compiled.

•  CSP/AD can easily access non-CSP programs in test, this is not always the case in VA Generator.

VA Generator is IBM's upgrade path for CSP customers, and should certainly be considered if your site has strong CSP 4GL skills.  It is a PC LAN-based tool which requires large powerful developer workstations, a high-speed LAN, and developers that have strong PC skills.  Depending on your current environment and programmer skill sets, this can either be a simple migration with some minor training required, or it can require major hardware and software upgrades and extensive training.  The source code resides in a LAN-based 'Envy' repository, which may be fine, or may cause extreme consternation with your audit department, depending on your situation.  VA Generator also requires that you have a current mainframe OS with the 'LE' option, which again can either be a simple check or a major roadblock, depending on your environment.

When migrating from CSP to VA Generator, it is important not to over-estimate the familiarity with the language. The 4GL is the same, but developing in the VA Java environment on a PC is very different. Code management and testing are two areas that are particularly prone to problems. Even experienced CSP developers will need training and mentoring. 

Depending on a number of factors, then, migrating to VA Generator can range from a simple, low-cost option at one extreme, to a difficult, expensive option at the other.

• Take inventory – often companies will find that a number of applications are no longer being used

• Validate Applications – don’t assume the applications are all correct, we often find errors and/or that the CSP source and executables do not match

• Map MSLs to Packages – it is unlikely that there will be a 1-to-1 relationship between MSLs and Packages, very careful consideration needs to be given to this step

• Install File Server and optionally a Generator Server

• Set-up Developer PCs

• Import into VA Generator and re-validate programs – don’t assume that because the application was valid in CSP that the program will be valid in VA Generator

• Test projects – some companies skip this step figuring that they have just re-organized the source code and they already have working executables. But remember the code has been re-organized and you are using a new editor and generator and you run the risk of a problem surfacing at a very inopportune time .i.e. during emergency production fix

• Modify Code Management procedures – this is often forgotten or under-estimated and requires careful consideration

• Train developers – this can be from some basic VA Generator IDE training to enable developers to maintain current 3270 programs to advanced Java/OOP for new systems).

For sites with strong COBOL skills and weak CSP 4GL skills, this is a good solution, since the converted code can be maintained by COBOL/CICS programmers using your standard code management tools.  Bridgewater has an automated process to convert CSP ESF into native COBOL / CICS / BMS, so the conversion process is not expensive, but the converted code must all be tested.  If you are renting the CSP software now, the savings could pay for the conversion.  The converted code will also use significantly less CPU cycles per transaction, and this saving in MIPS can translate into dollars.  Another side benefit of moving to a CICS/BMS system is that it allows the use of the IBM CICS/TS CWS option to put an HTML web front-end on the BMS maps, allowing a very inexpensive web interface to the system. 

Programs generated from CSP and VA Generator make heavy use of runtime routines, which impair performance. A CICS transaction converted to COBOL often uses 5 times less CPU cycles. The runtime routines also have associated fees, which can be eliminated.

VA Generator runtime requires up-to-date versions of OS/390, COBOL, and LE.  Some sites find these requirements to be a show-stopper. VA Generator requires high-powered developer PCs and servers, developer training and code management changes. CSP and VisualAge Generator require rare specialized programming skills that can be difficult to acquire and retain.

Converted COBOL can be maintained using existing development and code management tools, without staff-training issues.  

• Take inventory – often companies will find that a number of applications are no longer being used

• Validate Applications – don’t assume the applications are all correct, we often find errors and/or that the CSP source and executables do not match

• The CSP programs are exported from MSLs into ESF (an 80-byte text file)

• The ESF files are downloaded and sent to Bridgewater

• ESF is converted into COBOL source, copybooks and BMS

• Converted code is moved to the target development region

• PPT, PCT, RCT CICS entries are created, DB2 Plans are created and bound

• A copy of the original CSP system is kept in another development region so that a parallel test can be run

• Customer tests the Project(s) and Bridgewater fixes any conversion problems

Whether you decide to migrate your CSP code to VisualAge Generator, convert it to COBOL, or a combination of both Bridgewater can help. We can work with you on all aspects of the migration including

• Planning

• Software Installation

• Code Conversion

• Developer Training

For more information, please contact us at information@bridgewater.com or call (858) 486-5755

We are an eight year old San Diego based software development and professional services firm dedicated to helping organizations significantly reduce application development times without sacrificing current best practices or maintenance procedures

• Certified Sun Java, IBM VisualAge Java and DB2 consultants

• We have over 100 satisfied clients around the world including Avon Products, Pershing Brokerage, Hyundai, IBM, and USDA

• Our flagship product is BW*Wizard: a code generator which significantly increases the productivity of application development teams by producing pure source code (Java, COBOL, or VisualAge Generator) in minutes that would take days to hand code

• We have worked with CSP since 1980

• In 1990, we developed a CSP-to-COBOL converter, called BWCBLGEN

• We have worked closely with the IBM RTP Lab, and have performed VisualAge Generator training and consulting for IBM in the US, Europe, Canada, Brazil, New Zealand, and Korea

Bridgewater assisted Avon Products, NY, to migrate about 250 programs from CSP 4.1 to VisualAge Generator 4.0. We trained five mainframe developers in the new environment. Once the mainframe software requirements were installed, it took four weeks to migrate the source code into the ENVY repository, and a further four weeks of training and mentoring to get the developers up to speed.

• Security Pacific Bank: when moving a distributed loan system back to a central CICS system, we reduced the CPU load by converting the most-used transactions

• SDGE: we converted the cash payment and booking system as well as two other systems to enable SDGE to discontinue their CSP license, and to use their COBOL-skilled staff to maintain the system

• Unigroup (United Van Lines): we converted  a system for a group that had a skill shortage – they could not find developers with the 4GL skills

• Michelin: we converted all their VA Generator code to COBOL, because the 4GL was not supported at their site, and they wanted to save the runtime license costs

References can be supplied upon request.