Changes not made by the V7.0 migration tool

When you migrate to EGL version 7.0, the migration tool might not make all of the necessary changes.

After you migrate your code to V7.0, you might need to make the changes described in the following sections:

Updating project builders

When you import a migrated project into a V7.0 workspace, the Generation Results view might indicate that a part cannot be generated because a default build descriptor is missing; this can occur even if you have set a default build descriptor.

To resolve this issue, update the builders for the project so that the EGL Advanced Builder is listed after the EGL Build Parts Model Builder and the EGL Validation Builder.

To edit the build order in this way:
  1. In the Project Explorer view, right-click the project and then click Properties.
  2. In the Properties window, click Builders.
  3. On the Builders page, select EGL Advanced Builder.
  4. Using the down arrow button, move EGL Advanced Builder under EGL Build Parts Model Builder and EGL Validation Builder.
  5. Click OK.

Changes in property resolution

If you define a part with the same name as an EGL property, EGL might resolve references to that name with the user-defined part, rather than the EGL property.

Adding lengths to DECIMAL types

If you migrated a stringAsDecimal function, the migration tool might add a cast to the DECIMAL type to maintain the behavior of the old code. In this case, you must manually add a length.

For example, assume the following old code:
myStringNumber string = "5";
myResult decimal(7,2);
myResult = stringAsDecimal(myStringNumber) + 5;
The tool migrates this code to the following:
myStringNumber string = "5";
myResult decimal(7,2);
myResult = myStringNumber as decimal() + 5;
Add a length to the DECIMAL type,
myStringNumber string = "5";
myResult decimal(7,2);
myResult = myStringNumber as decimal(7,2) + 5;

Renaming variables or functions

You cannot have a variable and a function within a logic part with the same name. Rename the variable or the function.

Adding parentheses to called programs

Programs that are the target of a call statement must have a parameter list. This parameter list can be empty, but the parentheses denoting the parameter list are now required.

Removing outdated service references

The migration tool attempts to remove outdated service references from metadata files in the projects you migrate. However, it cannot remove the references if either of the following circumstances apply:
  • You did not install the IBM® WebSphere® Application Server development tools optional component, or your version did not include IBM® WebSphere® Application Server and the related development tools
  • You are generating Java™ code into a project on which you did not run the migration tool
In either of these cases, you must remove outdated service references from your metadata files manually:
  • For EGL web projects, if you added service references to the web deployment descriptor file manually, delete any EGL-generated service references from the file and retain any manually added references. If you did not add any service references to the file manually, you must delete the file. In most versions of J2EE, the web deployment descriptor is named web.xml and is located in the WebContent/WEB-INF folder of the project. On J2EE 1.3, the file is named webservicesclient.xml and is located in the same place.
  • Similarly, remove any EGL-generated service references from the ibm-webservicesclient-ext.xmi and ibm-webservicesclient-bnd.xmi files, which are also found in WebContent/WEB-INF. If you added no references to these files manually, you can delete the files, but you are not required to.

Changing variable types in JSF Handlers

If a variable in a JSF Handler has the selectType property set to index, that variable must be an INT type.

Using the selectFromListItem property

When a variable has the selectFromListItem property, the value of the property cannot be a record array or an array of primitive variables within a record. The valid types are a data table column or an array of primitive variables that are not within a record. To use a record array or an array of primitive variables within a record as a list of selection options, use the selectedRowItem or selectedValueItem properties.

Using consistent record or array types to get and set attributes

The type of a record or array used to receive the value returned by the following j2eeLib GET functions must be the same type as the argument used to set the attribute in the corresponding SET functions:
  • getRequestAttr()
  • getSessionAttr()
  • getApplicationAttr()

The value that is returned by getRequestAttr() must be the same type as the argument you used for setRequestAttr() to prevent runtime errors.

EGL V7.0 saves only the business data from the object to reduce heap storage requirements.

Changes to generated names with underscores

The algorithm for preserving unique names when an EGL name contains characters that are invalid in Java™ names has changed. The underscore character ("_") now precedes the hexadecimal value for the invalid character. Java™ names generated from EGL names containing an underscore now include the 005 hexadecimal value.

For example, EGL generates the following Java™ names corresponding to the EGL name under_score_test:
  • Version 6: under_score_test
  • Version 7: under_005fscore_005ftest

This does not cause a problem between EGL programs if all programs are regenerated in version 7. However any non-EGL program that invokes an EGL program must be modified to use the new form of any names that contained underscores. This includes non-EGL clients of EGL services or Jasper Reports.

Changes to the generated WSDL for structured record parameters

The algorithm for generating the WSDL definition of a service parameter produces different code in version 7 for structured records. Any client that invokes the service must be modified to invoke the service with the new parameter name.

Resolving the behavior of arrays as "in" function parameters

When you use the in modifier on a parameter definition for an array, the argument element type must be the same as the parameter element type.

For example, the following sequence was valid in EGL version 6, but is tagged as invalid in version 7:
function main();
  arrayArg CHAR(50)[ ] = ["A", "B", "C"];
  showArray (arrayArg);  // invalid statement in Version 7
end

function showArray (arrrayParm CHAR(100) [ ] in)
  i, iEnd INT;
  iEnd = size (arrayParm);
  for (i from 1 to iEnd)
    writeStdOut (arrayParm[i]);
  end
end

Thein modifier on arrayParm means that a temporary local variable is allocated for the parameter when the function is invoked and the argument is assigned to the temporary variable on entry to the function. In version 6, the assignment resulted in a copy being made of the argument array. In version 7, the assignment is a reference to the array. Because array assignments in version 7 must be between arrays with the same element type, the showArray() invocation in main() is flagged as an error in version 7.

You can resolve this situation in two ways:
  1. Use the move statement to create a temporary copy of the argument that is compatible with the parameter declaration:
    function main() ;
  arrayArg CHAR(50)[ ] = ["A", "B", "C"];
  	tempArrayArg CHAR(100) [ ];
	  move arrayArg to tempArrayArg;
	  showArray (tempArrayArg);
	end
  2. Change the array element types to be the same so that a new array is not created on each function call. In the next example, the element types are changed to STRING because the customer applications are generated to Java™, where the STRING type performs better than CHAR:
    function main();
  arrayArg STRING[ ] = ["A", "B", "C"];
  showArray (arrayArg);  // invalid statement in Version 7
end

function showArray (arrrayParm STRING[ ] in)
  i, iEnd INT;
  iEnd = size (arrayParm);
  for (i from 1 to iEnd)
    writeStdOut (arrayParm[i]);
  end
end

Changing link extensions

Links to JSF pages are specified on forward to url statements and on the action property for variables defined with displayUse = hyperlink. The EGL version 7 migration tool automatically changes the link extension from .jsp to .faces if the URL or action is specified as a literal value ending in .jsp. This change must be made manually if the link value does not end in .jsp or the value comes from a variable rather than from a literal.

Changing defaultDateFormat build descriptor option

In string-to-date conversion in version 7, the order of day, month, and year in the string must be the same as the order of day, month, and year in the defaultDateFormat build descriptor option. For the default values when this build descriptor option is not specified, see defaultDateFormat (build descriptor option).

In version 6, the conversion algorithm assumed a yyyyMMdd format. As a result, a date value such as "20050810" can cause an error in version 7 unless you explicitly set the defaultDateFormat build descriptor option to yyyyMMdd.

Defining build descriptors for print forms

In VisualAge® Generator and in EGL version 6, the default decimal and separator characters for print forms came from the language-dependent options module specified for your runtime installation. Beginning with version 7, the decimalSymbol and separatorSymbol build descriptor options determine those characters. In version 7 and later, the default value for the decimalSymbol option is a period, and the default value for the separatorSymbol option is a comma. If these values are not appropriate to your location, you must explicitly set these build descriptor options.

Considering other build descriptor options

Recent versions of EGL introduced several build descriptor options to affect behavior that changed over time. Please consider them in light of the EGL version from which you are migrating:
  • v60DecimalBehavior
  • v60NumWithCharBehavior
  • v60NumWithDateBehavior
  • v60SQLNullableBehavior
  • v71AddBehavior