Debugging EGL applications

Debugging is the process of monitoring the execution of a program to pinpoint the causes of errors. With the EGL debugger, you can set breakpoints (places for execution to pause), examine or change variables, and move through the program one step at a time. You can debug the following code:

• Programs
• Web transactions
• Rich UI Handlers

The simplest case of debugging involves the following steps:

• Select a preference to suspend the program. Click Window > Preferences > EGL > Debug. Under Suspend Execution, click Stop at the first line of the initial run unit.
• Choose the file to launch, based on the UI technology:
  • For web transactions, right-click EGLWebStartup.jsp and click Debug As > Debug on Server.
  • For batch programs, right-click the .egl file and click Debug As > EGL Program.
  • For Rich UI, right-click the .egl file and click Debug As > EGL Rich UI Application. For more information, see Rich UI debugging.
• Start the program.
• The code suspends at the first line of the run unit, and EGL asks if you wish you change to the Debug perspective. Click Yes.
• Click the Step Into button to move through the program

The debugger uses JDBC for SQL access, which creates the following differences from running on environments where JDBC is not used:

• JDBC does not support two-phase commit. There are separate calls to the SQL manager and WebSphere® MQ (formerly MQSeries®) manager for commit and rollback. Therefore, if a problem occurs, it is possible for one resource to commit or rollback without the corresponding commit or rollback for the other resource.
• JDBC always runs dynamic SQL. Generated COBOL uses static SQL except when you use the EGL prepare statement or a table name host variable (tableNameVariables property in the SQLRecord definition). Therefore, there are the following differences:
  • In dynamic mode, single row select can result in more than one row being returned without setting sysVar.sqlData.sqlCode to -811. As long as there is only one row that satisfies the criteria you do not notice a difference. See the following sample technique for how you can address this difference if it is important to you.
  • JDBC converts data that is defined on the host as a CHAR, DBCHAR, or MBCHAR SQL column with the "FOR BIT DATA" option. If you have this situation, set the asBytes property to YES for the field that corresponds to the SQL column that is defined as "FOR BIT DATA".

The following limitations also apply to both Debug and Java™ programs. There is a difference between Debug and generated COBOL programs, but no difference between Debug and generated Java™ programs:

• Be sure to use the DATE, TIME, and TIMESTAMP primitive types when defining fields for SQL columns that contain these types. You can use the CHAR primitive type, as long as the CHAR variable has the sqlDataCode property set to indicate the type of the SQL column. You can also use CHAR without the sqlDataCode property, but when you omit the sqlDataCode, you must rely on the JDBC driver to convert the dates to CHAR format. For further information on sqlDataCode, see sqlDataCode
• Certain SQL information is not supported by JDBC:
  • sqlLib.sqlData.sqlerrmc
  • sqlLib.sqlData.sqlwarn[n]
  • sysVar.sqlData.sqlerrmc
  • sysVar.sqlData.sqlwarn[n]

There is a technique you can use when the debug environment is different from the host environment: In the EGL -> Debug preferences, select Set systemType to DEBUG. In the EGL program you can include logic such as the following:

	if (sysVar.systemType is debug) 	
	   // do nothing
	else
	   //  check for sysVar.sqlData.sqlCode = -811 
	end