Answer: Yes. The transaction support integrates with Pervasive Btrieve to provide transaction support for VSAM files and with SQL Server to provide transaction support for SQL databases. The transaction support is provided using plug-in modules that you can replace if you want to tailor the behavior to your own particular requirements.

Although the .NET Framework is an object oriented system many of its functions can be invoked from procedural code and behaviors that require inheritance of particular classes can often be coded separately to be invoked from the procedural code. Thus the NeoKicks migration of CICS COBOL code to execute in the .NET environment brings the .NET Framework class libraries within a usable range of the COBOL code.

NeoKicks is designed to work with NetCOBOL for .NET and Visual Studio 2008. A suitable version of Visual Studio 2008 for working with COBOL is provided with NetCOBOL for .NET. If you generate the ASP.NET pages (output from the NeoKicks Project Wizard) in C# or Visual Basic, you will need a version of Visual Studio that supports your selected language. Other products may be required depending on your applications’ needs. For example, you will need a relational database like SQL Server if your application uses SQL, and you will likely want to select NeoData to provide transactional support for your COBOL file I/O.

We recommend that the first application(s) you modernize with NeoKicks should not be too large, should be self-contained and should use standard CICS file I/O or DB2 SQL commands. The choice of such applications allows you to become acquainted with the NeoKicks environment and the best legacy modernization techniques to use, without the distractions of the complexities of migrating large, interrelated systems or dealing with nonstandard database structures. Once you have modernized a smaller, self-contained application, you can then take on bigger and more complex application modernizations.

One of the functions of the NeoKicks Project Wizard, the tool that takes your CICS COBOL and BMS macro code and populates a Visual Studio project, is to convert the EXEC CICS code into calls to NeoKicks services – in much the same way that the CICS preprocessor converts the EXEC CICS code. Consequently there are very few changes you need to make to your CICS code. Changes that may be required are in the areas of CICS statements that are not currently supported, a few IBM COBOL statements that are not supported by NetCOBOL, and changes to logic that assumes EBCDIC collating sequences or character values. Fujitsu Computer Systems and our consulting partners are well versed in these areas and can quickly identify and plan for the needed changes. The end result is a set of applications prepared for a long life in the .NET environment.

Yes, though NeoKicks provides support to make the transition easy. Unicode is a multi-byte encoding system and as such can require changes in field and record lengths – a possibly challenging exercise. NeoKicks therefore supports the data in ACP (ANSI Code Page, that we generally think of as “ASCII”) format, which is the best match for EBCDIC’s single-byte encoding. The NeoKicks system handles the conversions between ACP and Unicode required for interfacing with the .NET Framework.
Data is therefore converted from EBCDIC to the appropriate ACP. Tools are provided with NetCOBOL to assist with this data conversion.

Code also needs to be reviewed for points where its behavior may depend on EBCDIC values such as:
- EBCDIC values hard coded as hexadecimal constants
- Comparisons that assume the EBCDIC collating sequence order
- File I/O that assumes the EBCDIC collating sequence order
Fujitsu has considerable experience in this area and can help you in this CICS migration process.

The goal for all supported CICS statements is to provide support that gives the same behavior as you would receive using mainframe CICS. Where a mainframe behavior doesn’t have a .NET equivalent NeoKicks will warn you at the preprocessing stage and we can usually recommend actions to preserve the integrity of your application logic.

Provided the developer has some experience with Windows (so that mechanisms such as using a mouse and standard Windows interfaces are familiar) then the learning curve is reasonably short, primarily involving familiarization with the functions of Visual Studio and NeoKicks’ integration into that environment. For those unfamiliar with Windows allow more time for training in and familiarization with the environment and tools.

You migrate them to Windows/.NET using the NeoBatch/NeoSort/NetCOBOL for .NET combination. Because your CICS and batch COBOL programs are operating in the same environment you have the same level of integration you had on the mainframe. You also have the option of configuring things slightly differently so, for example, your data is stored on a database server while your online and batch processes work on separate servers – you determine the configuration that gives you the service characteristics you desire.

Updates to your application will generally be made using NeoKicks service calls, unless you choose to maintain a version of your source code that you put through the NeoKicks preprocessor every time you update the code.

By default the NeoKicks answer to this question is “minimal”. The appearance and keystroke handling of the Web or Windows forms generated by NeoKicks from the BMS macros is almost identical to those of mainframe CICS. The main difference is that instead of the screen being displayed in a 3270 emulator window (or on a 3270 terminal) the “screen” (actually a Web page or Windows form) is displayed within an Internet browser window or Windows dialog. The new NeoKicks interfaces are constructed using GUI controls but their style is set up to look like the character screen.

Switching the application platform with negligible impact on your users allows you to focus on the migration and not expending time and energy retraining users. Later you can make the switch in interface style at a time that is convenient for both you and your users, possibly introducing some highly useful interface enhancements at the same time.

By default the NeoKicks answer to this question is “minimal”. The appearance and keystroke handling of the Web or Windows forms generated by NeoKicks from the BMS macros is almost identical to those of mainframe CICS. The main difference is that instead of the screen being displayed in a 3270 emulator window (or on a 3270 terminal) the “screen” (actually a Web page or Windows form) is displayed within an Internet browser window or Windows dialog. The new NeoKicks interfaces are constructed using GUI controls but their style is set up to look like the character screen.

Switching the application platform with negligible impact on your users allows you to focus on the migration and not expending time and energy retraining users. Later you can make the switch in interface style at a time that is convenient for both you and your users, possibly introducing some highly useful interface enhancements at the same time.

NeoKicks converts the CICS screens to ASP.NET pages that use master pages and cascading style sheets to define the standard style for each page. By default NeoKicks generates pages that look and feel very similar to the CICS screens so that application users have an easy transition to the new system. Configuring the pages to have your own style, or common elements such as company logos, is straightforward using the master page and style sheets.

The answer to this question really depends on your experience with and understanding of your end-users. It’s unlikely that your end-users will respond well to a unilateral announcement that tomorrow their interfaces are changing from character to graphical style and that you think this is going to make them very happy indeed! A better approach may be to inform your user base, or end-user advisory panel (or whatever body/method you use to determine what new features are required), that because you have migrated to NeoKicks/.NET new interface abilities are now possible, presenting a list of examples of the types of enhancements that are relatively easy to make (such as drop down lists, calendar controls, or other business-specific controls that you have identified). Then, when they recognize the value of particular features and request that they be implemented, you’ll know that your users are ready to make the change and can plan a suitable timetable with them.