The following tables compare the VAGen function part with the EGL function part and describe how the migration tool handles the conversion.
The functions section is organized into the following tables:
Figure 88. Functions -- general syntax, description, parameters, return value, and local storage
VisualAge Generator 4.5
| EGL produced by the migration tool | Migration tool considerations |
---|---|---|
Function parts can contain the following:
| Function parts can contain the following:
An example of the format of a function invocation statement created by the migration tool is as follows: // Description Function functionName (functionParamterList) [ returns( returnItemType ) ] [ dataDeclarations ] [ beforeStatements ] [ I/O Statement ] [ afterStatements ] end // end functionName
|
The migration tool uses the I/O option, I/O object, and error routine to build the EGL I/O statement. See Figure 91 For details on how the migration tool handles the Description, Function return value, Function parameters, and Function local storage, see the following rows in this table. See the following for details on the migration of before and after statements:
See the following for details on I/O options and error routines:
For details on SQL statements, see the following tables in this section:
|
Description | Not applicable | The migration tool converts the function description to a comment that precedes the Function definition. |
Function parameters:
| Function parameters:
An example of the format of function parameters is as follows: ( parameterName typeInfo [ parameterType ] { , parameterName typeInfo [ parameterType ] } ) A specific example of function parameters is as follows: (parmSharedItem parmSharedItem field, parmNonSharedItem char(10) nullable, parmRecord parmRecord) |
Function parameters: The migration tool sets the type information as follows:
|
Function parameters:
| Function parameters:
| |
Function parameters:
| Function parameters:
| |
Function return value:
| EGL returns value:
returns( returnItemType ) // Description | If the function includes a return value, the migration tool migrates the data type, length, and decimals based the rules described in Figure 61. |
Function local storage:
| Function variable declarations:
|
Function local storage: The migration tool sets the typeInfo as follows:
|
Function local storage:
| Function local storage:
|
Figure 89. Functions -- EXECUTE I/O option
Figure 90. Functions -- I/O options for maps and UI records
VisualAge Generator 4.5
| EGL produced by the migration tool | Migration tool considerations |
---|---|---|
|
To display a text form, use the display statement. To print a print form, use the print statement. The following are examples of a display statement and a print statement: display mapName; print mapName;
| The migration tool converts to the display or print statement based on the map type. See DISPLAY statement for maps for details and potential problems. |
|
Use the converse statement. The following is an example of a converse statement: converse mapName; | No special considerations. |
| Use the converse statement. The following is an example
of a converse statement:
converse UIRecordName; | No special considerations. |
Figure 91. Functions -- I/O for records -- general information and I/O error routine
VisualAge Generator 4.5
| EGL produced by the migration tool | Migration tool considerations |
---|---|---|
VAGen record I/O:
| EGL record I/O:
If an I/O error routine is specified, the statements are enclosed within a try...end block. An example of record I/O with an error routine is as follows: try add recordName ; [onException error-routine ; ] end | The migration tool does the following:
|
An error routine is optional for functions that do I/O for
records.
|
An error routine is optional for functions that do I/O for records. An I/O example without an error routine is as follows: add recordName; An I/O example with an error routine is as follows: try add recordName ; onException error-routine ; end
| The migration tool does the following:
Special considerations apply for the migration of error routines that are function names. See Ambiguous situations for functions - File and database I/O error routines for details and potential problems. |
Error routine values:
EZECLOS EZEFLO EZERTN mainFunctionName nonmainFunctionName | onException block statements:
onException exit program; onException exit stack; Omit the onException statement. onException exit stack mainFunctionLabel; onException nonmainFunctionName(); |
Figure 92. Functions -- I/O options for serial, indexed, relative, and message queue records
VisualAge Generator 4.5
| EGL produced by the migration tool | Migration tool considerations |
---|---|---|
|
Use the add statement. The following is an example: add recordName; | No special considerations. |
|
Use the get next statement. The following is an example: get next recordName; | No special considerations. |
|
Use the close statement. The following is an example: close recordName; | No special considerations. |
|
Use the get statement. If you are doing a single row select, also use singleRow. An example without single row select is as follows:: get recordName; An example with single row select is as follows: get recordName singleRow; |
If Single row select is specified in VisualAge Generator, the migration
tool includes the EGL singleRow option.
|
|
Use the get forUpdate statement. The following is an example: get recordName forUpdate resultSetID; |
The migration tool always includes the resultSetID when migrating an SQL UPDATE statement. The tool sets the resultSetID to the function name followed by a customer-specified suffix. You can control the suffix with the Stage 2 VAGen Migration Syntax Preferences. Special considerations apply if the migration tool cannot determine if the
record is SQL or non-SQL. See SQL I/O with multiple updates for details and potential problems.
|
|
Use the delete statement. The following is an example: delete recordName; | No special considerations. |
(with or without UPDATE/SETUPD functionName
|
Use the replace statement. The following are some examples: replace recordName; replace recordName from resultSetID; |
If the UPDATE/SETUPD function name was included in VisualAge Generator, the
migration tool includes the resultSetID and sets the resultSetID to the
UPDATE/SETUPD function name followed by a customer-specified suffix.
You can control the suffix with the Stage 2 VAGen Migration Syntax
Preferences.
|
(with and without Declare cursor with hold)
|
Use the open statement. If you are doing a Declare cursor with hold, also use the hold option. The following are examples of both types of statement: open resultSetID for recordName; open resultSetID hold for recordName; |
The migration tool sets the resultSetID to the function name followed by a customer-specified suffix. You can control the suffix with the Stage 2 VAGen Migration Syntax Preferences. If Declare cursor with hold is selected in VisualAge Generator,
the migration tool includes the EGL hold option.
|
(with and without Declare cursor with hold)
|
Use the open forUpdate statement. If you are doing a Declare cursor with hold, also use the hold option. The following are examples of both types of statement: open resultSetID forUpdate for recordName; open resultSetID hold forUpdate for recordName; |
The tool sets the resultSetID to the function name followed by a customer-specified suffix. You can control the suffix with the Stage 2 VAGen Migration Syntax Preferences. If Declare cursor with hold is selected in VisualAge Generator,
the migration tool includes the EGL hold option.
|
with Model SQL Statement
|
Use the execute statement. The following is an example: execute modelType for recordName;
|
The migration tool sets the EGL modelType based on the VAGen Model SQL Statement value. If the VAGen Model SQL Statement is None, the migration tool omits the I/O
statement because the VAGen I/O statement did not do anything. The
migration tool includes the try, onException, and
end statements based on the function's I/O error
routine.
|
VisualAge Generator 4.5
| EGL produced by the migration tool | Migration tool considerations |
---|---|---|
General Information for modified SQL statements:
| General Information for modified SQL statements:
|
The migration tool uses the tables and table labels from the SQL row record to build the tables clause for the EGL I/O statement. Both table names and table name host variables are included in the table clause of the EGL I/O statement. If a required SQL clause is not stored in the function definition, the migration tool creates a default clause based on the record definition in the same way as in VisualAge Generator. The migration tool converts any !itemColumnName variables to their corresponding SQL column name. The migration tool converts VAGen comments (/*) to SQL comments (--) Special considerations apply if the SQL record and its alternate
specification record, if any, are not available during migration. See Ambiguous situations for functions - SQL I/O for details and potential problems.
|
Clauses that can be modified:
|
Use the add statement. The following is an example: add recordName with #sql{ insert into sqlTablename (columnName1, columnName2) values (valueInfo1, valueInfo2) }; | The migration tool creates the insert into clause based on the table name in the record definition. Special considerations apply. See Ambiguous situations for functions - SQL I/O for details and potential problems. |
(with and without Single row select) Clauses that can be modified:
|
Use the get statement. The following is an example without single row select: get recordName singleRow with #sql{ select Name1, Name2, Age from sqlTable1 sqlLabel1, sqlTable2 sqlLabel2 where Name1 = :Namex order by Age } into nameA, nameB, myage; |
If Single row select is specified in VisualAge Generator, the migration tool includes the EGL singleRow option. The migration tool creates the from clause based on the table
names and table labels in the record definition. Special considerations
apply. See Ambiguous situations for functions - SQL I/O for details and potential problems.
|
Clauses that can be modified:
|
Use the get forUpdate statement . The following is an example: get recordName forUpdate resultsetID with #sql{ select Name1, Name2, Age from sqlTable1 sqlLabel1 where Name1 = :Namex for update of Name2, Age } into Name1, Name2, Age; |
The migration tool always includes the resultSetID when migrating an UPDATE statement for an SQL record. The tool sets the resultSetID to the function name followed by a customer-specified suffix. You can control the suffix with the Stage 2 VAGen Migration Syntax Preferences. The migration tool creates the from clause based on the table
name or table label in the record definition. Special considerations
apply. See Ambiguous situations for functions - SQL I/O for details and potential problems.
|
(optional UPDATE/SETUPD functionName) Clause that can be modifed:
|
Use the replace statement. The following is an example of the replace statement: replace recordName with #sql{ update sqlTableName set columnName1 = value1, columnName2 = value2 } from resultSetID; |
If an UPDATE/SETUPD function name is included in VisualAge Generator, the migration tool includes the from resultSetID clause. The migration tool sets the resultSetID to the UPDATE/SETUPD function name followed by a customer-specified suffix. You can control the suffix with the Stage 2 VAGen Migration Syntax Preferences. The migration tool creates the update clause based on the table
name in the record definition. Special considerations apply. See
Ambiguous situations for functions - SQL I/O and SQL I/O and missing required SQL clauses for details and potential problems.
|
(with or without Declare cursor with hold)
(with or without Declare cursor with hold) Clauses that can be modified:
|
Use the open statement. If you are doing a Declare cursor with hold, also use the hold option. The following is an example of an open statement using the hold option: open resultSetID hold with #sql{ select Name1, Name2 from sqlTable1 sqlLabel1, sqlTable2 sqlLabel2 where Name1 > :Name2 order by Name1 } into Name1, Name2 for recordName; |
The tool sets the resultSetID to the function name followed by a customer-specified suffix. You can control the suffix with the Stage 2 VAGen Migration Syntax Preferences. If Declare cursor with hold is selected in VisualAge Generator, the migration tool includes the EGL hold option after the resultSetID. The migration tool creates the from clause based on the table
names and table labels in the record definition. Special considerations
apply. See Ambiguous situations for functions - SQL I/O for details and potential problems.
|
(with or without Declare cursor with hold) Clauses that can be modified:
|
Use the open forUpdate statement. The following is an example using the hold option: open resultSetID hold forUpdate with #sql{ select Column1, Column2 from sqlTable1 sqlLabel1, sqlTable2 sqlLabel2 where Column1 > :Item1 for update of Column2 } into Item1, Item2 for recordName; |
The migration tool sets the resultSetID to the function name followed by a customer-specified suffix. You can control the suffix with the Stage 2 VAGen Migration Syntax Preferences. If Declare cursor with hold is selected in VisualAge Generator, the migration tool includes the EGL hold option. The migration tool creates the from clause based on the table
name or table label in the record definition. Special considerations
apply. See Ambiguous situations for functions - SQL I/O for details and potential problems.
|
with Model SQL Statement
|
Use the execute sql statement. The following is an example of the statement: execute modelType #sql{ UPDATE mysqltable set Column1 = Column1 * 2 where Column2 = :Column2 } for recordName;
|
The migration tool does the following:
The migration tool includes the VAGen Model SQL Statement value, if any, as a comment on the EGL execute statement. The migration tool migrates the VAGen SQLEXEC clauses to EGL SQL
clauses.
|
Figure 95. Functions - I/O options for modified SQL statements with Exection Time Statement Build
VisualAge Generator 4.5
| EGL produced by the migration tool | Migration tool considerations |
---|---|---|
Execution time statement build can only be used with the following I/O
options:
You specify Execution time statement build to cause VisualAge Generator to prepare the SQL statement dynamically every time the I/O statement is executed. | In EGL, you code the SQL prepare statement directly whenever you want the
SQL statement to be dynamically prepared. You must also code the open,
execute, or get statement that follows the prepare. For example, the
EGL equivalent of a VAGen INQUIRY I/O option with Execution time statement
build is as follows:
prepare prepID from "sqlStatementString" for recordName; get recordName with prepID into itemList;
| The migration tool uses the SQL clauses in the function and the table
names and /or table name variables in the record definition to build the
sqlStatementString. The migration tool builds the sqlStatementString as
follows:
Then the migration tool does additional processing to create the sqlStatementString, including:
Special considerations apply if the SQL record and its alternate specification record, if any, are not available during migration. See Ambiguous situations for functions - SQL I/O and SQL I/O and missing required SQL clauses for details and potential problems. |
with and without Single row select Clauses that can be modified:
| Use the prepare statement. The following is an
example:
prepare prepID from " select columnName " + ", columnName2 " + " from table1 t1 " + "[ where whereClause ]" + "[order by orderByClause ]" [ for recordName ]; get recordname with prepID into itemList; | No special considerations. |
Clauses that can be modified:
| Use the prepare statement. The following is an
example:
prepare prepID from " select columnName " + ", columnName2 " + " from table1 t1 " + "[ where whereClause ]" + " for Update of columnList " [ for recordName ]; get recordName forUpdate resultSetID with prepID into itemList; | The migration tool always includes the resultSetID when migrating an UPDATE statement for an SQL record. The tool sets the resultSetID to the function name followed by a customer-specified suffix. You can control the suffix with the Stage 2 VAGen Migration Syntax Preferences. |
with or without Declare cursor with hold Clauses that can be modified:
| Use the prepare statement. The following is an
example:
prepare prepID from " select columnName " + ", columnName2 " + " from table1 t1 " + "[ where whereClause ]" + "[order by orderByClause ]" [ for recordName ]; open resultSetID [ hold ] with prepID into itemList [ for recordName ]; |
The migration tool sets the resultSetID to the function name followed by a customer-specified suffix. You can control the suffix with the Stage 2 VAGen Migration Syntax Preferences. If Declare cursor with hold is selected in VisualAge Generator,
the migration tool includes the EGL hold option after the resultSetID.
|
with or without Declare cursor with hold Clauses that can be modified:
| Use the prepare statement. The following is an
example:
prepare prepID from " select columnName " + ", columnName2 " + " from table1 t1 " + "[ where whereClause ] " + " for update of columnList " [ for recordName ] ; open resultSetID [ hold ] forUpdate with prepID into itemList [ for recordName ] ; |
The tool sets the resultSetID to the function name followed by a customer-specified suffix. You can control the suffix with the Stage 2 VAGen Migration Syntax Preferences. If Declare cursor with hold is selected in VisualAge Generator,
the migration tool includes the EGL hold option after the resultSetID.
|
with Model SQL Statement
| Use the prepare statement. The following is an
example:
prepare prepID from " grant " + group_privileges + " on " + table_name + " to " + userid [ for recordName ] ; execute prepID [ for recordName ] ; // model = type |
The migration tool includes the VAGen Model SQL Statement value, if any, as a comment on the EGL execute statement. The migration tool converts the VAGen SQLEXEC clauses to EGL SQL
clauses.
|
(C) Copyright IBM Corporation 1992, 2005. All Rights Reserved.