Migrating to VisualAge Generator
The following are some special considerations that apply when migrating
from Cross System Product to VisualAge Generator WorkGroup Services.
All C++ environments in VisualAge Generator (OS/2, AIX, CICS/6000, CICS for
Windows NT, and Windows NT) are new. For more information on the
compatibility considerations, refer to the VisualAge Generator
Reference document.
The following are considerations for member names:
- Application, map group, and table names:
- Must be unique
- Must not be C++ reserved words
The following gives an overview of the compatibility considerations for
language elements. The language elements include the following:
- Mapping support
- CONVERSE process option
- EZE special function words
- Transferring among applications
- File support
- Relational database (SQL) support
- DL/I database support
- Data values
- User message files
Migration considerations for mapping support are as follows:
- An automatic form feed for each printer file is issued whenever a main
application ends or when an application called by a non-VisualAge
Generator program returns to the calling program. An automatic form
feed is also issued for the current printer file when a CLOSE process option
is explicitly issued. No form feed occurs when an application starts or
when a called application returns to another VisualAge Generator
application. The automatic form feed can be suppressed by adding an
entry in the resource association file for EZEPRINT and specify the /NOFF
option.
- Only one definition of a floating area is supported for printers or
terminal maps. If different floating areas are defined for different
print devices (for example, PRINT, PRINT-B, 3767), the
definition that is used depends on the order in which the maps were defined
and cannot be predicted. To avoid confusion, either specify the same
device for all print and terminal maps or specify the same floating area for
all printers and terminal devices.
- The display of a negative zero value is different for CSP/AE and C++
applications. If a numeric variable field is defined with zero edit and
a leading or trailing sign, and a value -0 is moved to the item,
CSP/AE displays the negative sign. However, the same map field in
the C++ program will not display the negative sign. If the field is
defined with a trailing sign, it will be displayed as 0+ when running the
C++ program. If the field is defined with a leading sign, it will be
displayed as 0.
Migration considerations for the CONVERSE process option are as
follows:
- Execution mode can be changed dynamically by the application, using the
EZESEGM special function word. The execution mode of either
is converted to segmented for main transactions and to
nonsegmented for all other types. The execution mode is
converted when the application is imported into a VisualAge Generator
MSL. If an application that is not a main transaction has an execution
mode other than nonsegmented, it is changed to nonsegmented.
Under CSP/AD 3.2.2 or CSP/AD 3.3, execution
mode could be overridden at generation either online or in batch using the
generation option EXECMODE. In VisualAge Generator, this option is
specified during application definition, instead of at generation time.
- In VisualAge Generator, the default value for the segmented transaction
name in CICS is the name of the currently active transaction.
Migration considerations for EZE special function words are as
follows:
- In VisualAge Generator WorkGroup Services, the print destination is the
resource that is associated to the file name EZEPRINT in the resource
association file.
- The special function word EZERT8 always contains system dependent
codes. The /NOSYSCODES generation option is not supported.
Migration considerations for transferring among applications are as
follows:
- An XFER statement in a called application is not supported in any
environment. Restructure applications in a run unit so that the XFER
statement is performed by the main application.
- If an application is defined as segmented or single segment, a commit is
taken on an XFER statement.
- The NONCSP generation option must be specified for DXFR statements that
transfer to non-VisualAge Generator programs, either as an option on
the DXFR statement or in a DXFRLINK specification in the linkage table.
- Recursive application calls (for example: A calls B, which in
turn calls A) are not supported. Recursive use of processes and
statement groups in an application is supported.
Migration considerations for file and database support are as
follows:
- The file position (for serial, indexed, or relative files) after
an unsuccessful INQUIRY, UPDATE, SCAN, or SCANBACK is undefined. The
application must establish file position again when an unsuccessful read
occurs.
- SCAN position is set on any successful I/O to the file. SCAN
after any successful I/O operation retrieves the first record whose key
is greater than the key of the record accessed on the previous I/O
operation. If the record accessed on the previous I/O operation
was the last record in the file, SCAN returns end-of-file
(EOF).
- SET record SCAN results in an error message if used for serial or SQL
records. Under CSP/AE, SET record SCAN was ignored.
- A SCANBACK process on a file that is not initialized returns NRF. A
SCANBACK process on an empty file causes an EOF for non-CICS
environments and both an EOF and NRF for CICS environments. A file is
not initialized if it has never had any records in it. An empty file is
one from which all records have been deleted. In the native
environments (non-CICS), a SCAN or SCANBACK process on a file that does not
exist returns FNF.
- SCANBACK position is set on any successful I/O to the file.
SCANBACK, after any successful I/O operation, retrieves the record with
the highest key value that is less than the key of the record accessed on the
previous I/O operation.
- SCANBACK following a SET record SCAN retrieves the record with the highest
key value that is less than or equal to the current record key value. A
SET record SCAN with a key value set to all X'FF' bytes
prior to a SCANBACK sets the position to the end of the file. This
causes the next SCANBACK to retrieve the last record in the file.
- SCANBACK following a SCAN that returned an EOF retrieves the last record
in the file.
- SCAN following a SCANBACK retrieves the record following the record
accessed on the SCANBACK.
- When using alternate indexes, duplicate keys are handled as follows:
- A SCAN process returns the record in the file with the next higher
alternate key than the current position in the file. A DUP condition
occurs if the record retrieved using SCAN has the same key as another record
in the file.
- If records with duplicate keys exist in the file, a SCAN following a SCAN
retrieves any duplicate-keyed record before retrieving the record with
the next key. Records with duplicate keys are returned in the order
that the file system returns them.
- A SCANBACK process returns the record in the file with the highest
alternate key that is less than the current position in the file. A DUP
condition occurs if the record retrieved using SCANBACK has the same key as
another record in the file.
- If records with duplicate keys exist in the file, a SCANBACK following a
SCANBACK retrieves any duplicate-keyed record before retrieving the
record with the previous key. Records with duplicate keys are returned
in the order that the file system returns them.
Migration considerations for SQL applications are as follows:
- Data items must be defined with a variable-length SQL code for
variable-length data values to be written to the table. Data
items must also specify the same length to VisualAge Generator as defined in
the SQL table.
- The following SQL data codes are not supported for HEX data items:
- 460 and 461, which are varying length, optionally null-terminated
characters. VisualAge Generator equivalent is CHA data with no SQL data
code specified.
- 484 and 485, decimal. The number of decimals cannot be specified
for HEX data items. VisualAge Generator equivalent is PACK data with no
SQL data code specified.
- Large applications can result in a generated C++ application that exceeds
the DB2 SQL statement precompiler limits, depending on your release of
DB2.
The following are examples of precompiler limits:
- Maximum number of processed lines--All SQL statements must occur in
the application prior to this limit.
- Maximum number of unique host variables--Each host variable that
allows nulls also has an indicator variable that counts toward the
maximum.
Refer to the DB2 documentation for more information on precompiler limits
for processed lines or unique host variables.
-
All application SQL statements are generated directly into the C++
program. There is no dynamic SQL runtime option for
applications. The only SQL statements that run dynamically at run time
are those that have a dynamic table name (table name in the SQL row
record is a host variable) or those for which the Execution Time
Statement Build option was specified in the SQL statement definition.
Any application that does not run in static mode with CSP/AE will not
work as a generated C++ program in VisualAge Generator without being modified
to specify a dynamic table name or Execution Time Statement Build option for
any statement that must be run dynamically. Using dynamic table names
is the preferred option because Execution Time Statement Build has effects on
the operation of other character host variables within the SQL
statement.
- Several differences exist between the SQL support provided by the DB2
family of products on various platforms. These differences are listed
in the Formal Register of Extensions and Differences in SQL (SC26-3316) document.
Migration considerations for DL/I applications are as follows:
- DL/I applications are not supported in the C++ environments.
Migration considerations for data values are as follows:
- All records are initialized according to data type; in CSP/AE, they
were initialized to blanks.
- If the application is a client/server application and runs on AIX, the
CONTABLE parameter is required in the client linkage table in order to
eliminate data alignment problems.
Migration considerations for user message files are as follows:
For the CICS environment, the X'FFFFFFFF' fullword at the end of
the parameter list is consistent with the CSP/AE CALL interface.
The length of the COMMAREA does not include this fullword unless
/ENDCOMMAREA is specified as a C++ generation option for the calling
application. If the generation option /ENDCOMMAREA was specified
and the parameter format COMMPTR is in effect, the length specified for
COMMAREA on the EXEC CICS LINK command is automatically increased by 4
bytes. Under certain conditions, CICS passes a copy of the COMMAREA to
the called application. Specify /ENDCOMMAREA to ensure that the
X'FFFFFFFF' fullword is included when a copy of the COMMAREA is
made.
The NLS code has been extended to 3 characters. The first two
characters define the base language (for example, EN is for
English). The third character can either represent natural
continuation or identifies variation, script, or dialect. The NLS codes
are as follows:
Table 11. Language Support Suffixes
Description
| V3.3
| VisualAge Generator
|
Default language
| D
| See note.
|
U.S. English (Mixed case English)
| E
| ENU
|
Uppercase English
| U
| ENP
|
Simplified Chinese
| C
| CHS
|
German (Germany)
| G
| DEU
|
German (Switzerland)
| W
| DES
|
Japanese
| J
| JPN
|
Korean
| K
| KOR
|
Portuguese (Brazilian)
| P
| PTB
|
Note: | The default language is specified as an installation option. A unique
code for the default language is no longer required.
|
|
CSP/AE invocation parameters have been replaced with generation
options, installation options, or are no longer supported.
Table 12 shows how CSP/AE invocation parameters are supported
when using generated C++ applications.
Table 12. Invocation Parameter Migration for CSP/AE
Parameter
| Corresponding Function in VisualAge Generator
|
P=yyyy
| The application developer can specify an alternate print destination by
adding an entry for EZEPRINT in the resource association file. The
application can dynamically change the print destination by using the special
function word EZEDESTP.
|
NLS=n
| The NLS code for VisualAge Generator WorkGroup Services is specified at
run time with the EZERNLS environment variable.
|
SEG
| The application switches between segmented and nonsegmented mode by
setting EZESEGM.
|
DMODE=S|D|A
| In the C++ environments, only DB2 SQL statements are generated.
|
RT=zzzz
| The RT option is specified at generation time through the /RT
generation option. The application user no longer has to press
attention interrupt to go on to the next transaction; the transaction is
started automatically.
|
TSMS
| The /WORKDB generation option specifies whether auxiliary or main
temporary storage is used for saving working storage across segments.
|
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]