VisualAge Generator to Enterprise Generation Language Migration Guide
The following runtime behavioral differences can occur without any messages
in the migration log or the Tasks list. The problems can occur during
debug or when running the generated Java or COBOL code:
- The following apply to text programs:
- A runtime error occurs if a form field is not long enough to contain all
the digits and formatting information (sign, decimal point, currency symbol,
and numeric separator).
- Non-default fill characters are always honored, even if the program does
not issue a SET formItem FULL statement.
- If a record that is a VAGen REDEFINED record is not available when
migrating a program, the migration tool does not include the EGL
redefines property in the data declarations. This results in
two separate record areas, rather than a single area with two definitions as
in VisualAge Generator. Errors, including abends, can result due to
uninitialized or invalid data. See Redefined records for details.
- Hard I/O errors occur in more situations in EGL than in VisualAge
Generator:
- In VisualAge Generator, UNQ for non-SQL records is a soft error so the HRD
I/O error state is not set. In EGL, unique is a hard error
so hardIOError also tests true. See I/O error values UNQ and DUP for details.
- For iSeries, the VAGen I/O error value LOK is migrated to the EGL
deadlock I/O error state. In VisualAge Generator, LOK is a
soft error so the HRD I/O error state is not set. In EGL,
deadlock is a hard error so hardIOError also tests
true. See I/O error value LOK for details.
- If the I/O error routine is not available when migrating a function, the
migration tool assumes that the I/O error routine is not a main function and
converts to a function invocation. In VisualAge Generator, if the I/O
error routine is a main function and an error occurs at runtime, VisualAge
Generator clears the current execution stack of functions and starts a new
stack with just the main function that is specified as the I/O error
routine. This also clears out any storage for the execution
stack. In EGL, because the migration tool converted to a function
invocation, if an error occurs at runtime, EGL adds the main function to the
current execution stack rather than cleaning out the stack and starting a new
stack with just the main function. This has the potential for an
infinite loop or a large use of resources if functions have local storage or
parameter lists. See Ambiguous situations for functions - File and database I/O error routines for details.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]
(C) Copyright IBM Corporation 1992, 2005. All Rights Reserved.