SQL Code Generation Options

Restriction: This topic applies to Windows environments only.

Before you begin compiling, testing, and executing your HCOSS code, consider what you want HCOSS to do for you.

To convert the mainframe SQL in my programs such that it works with SQL Server: Set the DIALECT SQL compiler directive option to MAINFRAME to convert all SQL, or MIXED to convert selected EXEC SQL statements in the code. To fully enable compile-time checking of converted SQL statements using SQL Server, set the DB, PASS and QUALIFIER directives along with DIALECT=MAINFRAME or DIALECT=MIXED. For additional information, see the DIALECT Statement Prefixes and the Application Progression from DB2 to SQL Server topics.
To mimic mainframe-style binding with my application: Specify the DBRMLIB SQL compiler directive option. If required to fully emulate your mainframe setup, you can also specify the MEMBER and VERSION directives. For additional information, see the Building Applications topic.
Note: Packages and plans are stored as SQL Server stored procedures.
To manage the application using SQL Server stored procedures: For HCOSS to manage your application using SQL Server stored procedures for your applicable SQL statements, but not manage them via packages or plans, specify either the ACCESS or BIND SQL compiler directive option.
Only to embed SQL into the generated code: To have HCOSS simply embed SQL into the generated code, no compiler directive options are required. This is the default behavior.

The following table provides a quick reference to the SQL compiler directive options that affect code generation. For complete information on each, see the appropriate Reference topic.

SQL Compiler Directive Option	Generation Specifics	Advantages
None (default)	SQL remains embedded in object code	Simplicity
ACCESS	Creates a stored procedure at compile time for most static SQL statements	Convenient for testing when the BIND SQL compiler directive option is to be used for deployment.
BIND	Enables deployment of application code by generating an SQL batch script that can be used with sqlcmd or SQL Server Management Studio to update the SQL Server database.	Security can be applied separately to procedures and data so that application users can only access and update data via the application. DBAs can review SQL that is to be deployed without having to access source code.
DBRMLIB¹	Enables generation of DBRMs containing the static SQL statements from COBOL programs, mimicking mainframe-style binding.	Mainframe deployment compatibility, meaning you can bind using existing JCL. You can bind a DBRM multiple times using different parameters each time, such as different default qualifiers. You can apply security separately to procedures and data so that application users can only access and update data via the application. You can use the Manage Packages and Plans tool to manage DBRM binding and freeing. Enables HCOSS to maintain mainframe-compatible metadata in the database for bound packages and plans. DBAs can review SQL after binding by browsing stored procedures without having to access source code.
DIALECT²	Converts DB2 SQL statements that are not compatible with SQL Server into equivalent T-SQL statements in most cases.	You do not need to convert DB2 statements to T-SQL. You can change the default schema when a program is bound, or in some cases, change the default schema at compile time using the QUALIFIER SQL compiler directive option.
¹ For additional information, see also the Building Applications topic. ² For additional information, see also the DIALECT Statement Prefixes and the Building Applications topics.