Data Type Parameters in COBOL and SQL CLR Stored Procedures

Standard COBOL stored procedure parameters (arguments) use COBOL data types. SQL CLR stored procedure parameters use .NET data types. To successfully run a COBOL stored procedure in a SQL CLR environment, its input parameters must use .NET data types when the stored procedure is invoked, and its output parameters must also use .NET data types when it returns to the calling application. You have the option to provide Enterprise Developer with COBOL stored procedures that use either COBOL or .NET data type parameters. Which option you choose might depend on several factors. Consider the following to help you determine the best option:

COBOL Stored Procedures with .NET Data Type Parameters

Providing COBOL stored procedures that use .NET data type parameters can be the correct option depending on your COBOL application.

Advantages

If you are creating new stored procedures, you can use OpenESQL Assistant to automatically generate the code with .NET data type parameters. For this option, generate the stored procedure from OpenESQL Assistant and then add its artifacts to your Enterprise Developer project as existing SQL CLR objects. For details, see the Stored Procedures sub-topic of the Using OpenESQL Assistant section in this documentation.
Note: While not necessarily an advantage or a disadvantage, you also have the option to manually code new SQL CLR objects using the editor in Enterprise Developer. New manually coded files are created as part of your Enterprise Developer project and do not require any advance preparation other than determining how you want to code data type parameters. See SQL CLR Integration Process for details.
No SPD file or wrapper program is required to successfully execute the COBOL stored procedure with your COBOL application.

Disadvantages

If you have existing COBOL stored procedures that use COBOL data type parameters, you must manually edit the code and change them to .NET.

COBOL Stored Procedures with COBOL Data Type Parameters

Similarly, providing COBOL stored procedures that use COBOL data type parameters can be the correct option, again depending on your COBOL application.

Advantages

This is a convenient option if you already have COBOL stored procedures and you need to migrate them to SQL Server. In this case, you can use your existing code as is.
Note: While not necessarily an advantage or a disadvantage, you also have the option to manually code new SQL CLR objects using the editor in Enterprise Developer. New manually coded files are created as part of your Enterprise Developer project and do not require any advance preparation other than determining how you want to code data type parameters. See SQL CLR Integration Process for details.
By supplying a Stored Procedure Definition (SPD) file, Enterprise Developer does the COBOL to .NET conversion for you using a generated COBOL wrapper program. See COBOL Wrapper Programs for details.
You can pass COBOL group variable names by defining parameters in the SPD file. For details, see Stored Procedure Definition (SPD) File.

Disadvantages

This option does require the additional step of creating an SPD file and using a COBOL wrapper program around your stored procedure. See COBOL Wrapper Programs and Stored Procedure Definition (SPD) File for more information.