=================================
RELEASE NOTES
FOR
INFORMIX 6.04.UC1 PRODUCT RELEASE
DATE: 05/13/96
=================================
TABLE OF CONTENTS
I. OVERVIEW OF RELEASE NOTES
II. PRODUCTS CONTAINED IN THE 4.16/6.04 TOOLS RELEASE
III. SPECIAL CONSIDERATIONS FOR DEVELOPERS USING 4.16/6.04 RELEASE SOFTWARE
IV. BUGS FIXED IN RELEASE 4.16/6.04
V. KNOWN PRODUCT DEFICIENCIES
VI. RELEASE NOTES AND NEW DOCUMENTATION
I. OVERVIEW OF RELEASE NOTES
The purpose of these release notes is to inform the user of changes in
products that might affect existing applications. The release notes
contain information on changes from previous releases, known problems,
and work-arounds. Bug identification numbers are assigned to known
problems to assist you in identifying the problems to Technical Support.
This document is not all-inclusive but is a tool to assist you in the
upgrade process. Please consult Informix product manuals for additional
information on product features and for clarification of product
behavior.
The 6.04 Tools release is feature-equivalent to the 4.16 release, but
it adds the ability to communicate directly with version 6.00 or higher
Servers releases (avoiding the overhead of using the Relay Module), and
it adds National Language Support (NLS). However, the 6.04 tools will
not work with any servers releases earlier than 6.00.
Because 4.16 and 6.04 are concurrent releases, we expect that customers
who need to work with version 6.00 or higher servers, or who need NLS
functionality, will probably skip the 4.16 release altogether. For this
reason, the 4.16 and 6.04 release notes have been combined into this
common document. Customers who have both releases will notice the
inherent duplication in the release notes.
Readers who are upgrading from 4.XX version to 6.XX version should read
the release notes contained in TOOLREL_6.0 for details on how the
environment change will affect them. Similarly, Readers who are
updating from a version earlier than 4.13/6.01 should read the
TOOLREL_6.0 or TOOLREL_4.0 notes, and users updating from 4.13/6.01
should read TOOLREL_4.14/TOOLREL6.02 as appropriate, for a wealth of
information about changes that may affect them.
II. PRODUCTS CONTAINED IN THE 4.16/6.04 TOOLS RELEASE
The following products are contained in the 4.16/6.04 tools release:
Product Name
------------
INFORMIX-4GL
INFORMIX-4GL Runtime Facility
INFORMIX-4GL/Rapid Development System
INFORMIX-4GL/Rapid Development System Runtime Facility
INFORMIX-4GL/Interactive Debugger
INFORMIX-SQL
INFORMIX-SQL Runtime Facility
III. SPECIAL CONSIDERATIONS FOR DEVELOPERS USING 4.16/6.04 RELEASE SOFTWARE
INSTALLATION
============
We recommend that the 4.16/6.04 Tools be installed in a newly created
directory, followed by the appropriate Servers product(s), rather than being
installed on top of previous versions of Informix products. Many files
have been relocated or renamed. It will be much easier to remove
redundant files if the old $INFORMIXDIR directory can be removed
completely (after testing the new installation, of course) than if you
have to spend time removing old files manually.
COMPATIBILITY
=============
There is no new 4gl syntax introduced in this release, nor has the
RDS pcode level been changed. There should be no problems recompiling older
applications to take advantage of the bugfixes in this release, and
Interpreter pcode generated by 4.16/6.04 should be runnable by a 4.14/6.02
Interpreter runner, and vice versa.
There have been significant compatibility problems with RDS pcode in
the past that might affect users upgrading from releases older than
4.14/6.02; users in that situation should be sure to refer to the
"COMPATIBILITY" sections in the other TOOLREL_X.XX documents, as mentioned
in section I.
As in the past, customers should not mix different versions of
different products of the Tools releases within the same directory.
For example, if a customer were to install a INFORMIX-4GL 6.04 Rapid
Development System in the same directory as an existing 6.02
INFORMIX-4GL Compiler System, errors may result in the older product.
This is because the products share some libraries, but not other
libraries, and overwriting an older existing library with a newer
library can lead to a mismatch between the older product's call to a
function within that library and the new library's function
signature.
Though the example given is between the two flavors of INFORMIX-4GL,
this situation is true for any combination of INFORMIX-4GL, INFORMIX-SQL,
INFORMIX-4GL/Interactive Debugger, and INFORMIX-4GL/Rapid Development
System.
BUG FIXES OF SPECIAL NOTE
=========================
8534: PRINTING A BLOB IN A AFTER GROUP BY DISPLAYS A WRONG BLOB
==================================================================
The method by which 4GL passes an argument between the calling routine
and the function depends on the data type of the argument. Except for
variable of data type BYTE and TEXT, arguments are passed to the
function by value. That is, a copy of the argument is passed. In
this case, changing the value of a formal argument within the function
has no effect in the calling routine. In contrast, 4GL passes arguments
of data type BYTE and TEXT by reference. In this case, the function
works directly with the actual variable, rather than a copy. That is,
changing a reference to a formal argument in a function changes the
corresponding variable in the calling routine and vice versa.
The call-by-reference nature of 4GL in dealing with the BYTE/TEXT type
arguments had caused some problems in 4GL/ACE reports where the
AFTER GROUP OF clause mandates that when 4GL/ACE executes the statements
in an AFTER GROUP OF control block, the local variable should have the
value from the last record of the current group. With call by reference,
the value of the BYTE/TEXT field of the first record from next group would
have already been retrieved into the corresponding report variable when
the AFTER GROUP OF block is executed, To fix this problem, a report
needs to receive BYTE/TEXT type arguments by value; this new, changed
behavior is implemented on 4GL/ACE reports only starting with 4.16/6.04
release.
Non-report type 4GL functions still receive arguments of BYTE or TEXT
data type by reference as before.
15821: PROMPT WITH COLOR ATTRIBUTE DOES NOT WORK
================================================
(This in not a bug; what follows is an addendum to documentation on
this subject.)
The PROMPT statement produces output in whatever is the current
display mode, i.e. either Line Mode or Formatted Mode. Users should be
aware that when executing in Line Mode, 4GL ignores any display attributes
specified in the PROMPT statement -- the prompt string as well as the
prompt response will be displayed in default attributes as if no attributes
were specified.
This behavior, although not explicitly pointed out in previous
documentation, has been consistent in all releases of 4GL.
25377: VERSION 6.00 AND EARLIER ISQL FAILS WHEN RUN AGAINST 7.00
FRAGMENTED TABLES
================================================================
(This is not a bug; the information that follows is available in other
documentation, but is re-presented here because customer's have shown
particular interest in this topic.)
ISQL does not support those server features that are specific to
server versions 5.0 and greater (except that ISQL Version 6.0 provides
National Language Support (NLS) functionality). A specific example of
5.0+ server feature that is not supported by ISQL is the INFORMIX-OnLine
Dynamic Server's Fragmented Tables feature.
However, the 7.X INFORMIX-OnLine Dynamic Server provides a method for
making fragmented tables which are usable with ISQL, using the WITH ROWIDS
option. If the user or DBA creates all affected tables using the CREATE
TABLE or ALTER TABLE statement with the ADD ROWIDS option, the server
will add an artificial ROWID column to that table. The addition of this
column will allow ISQL to work with fragmented tables.
35959: INPUT ARRAY: SPURIOUS SCROLL-DOWN OF PREVIOUSLY DISPLAYED DATA
(FROM FIELD DEFAULTS OR MANUAL DISPLAYS) OCCURS WHEN INPUT ARRAY
TAKES CONTROL
42072: INPUT ARRAY SCROLLS ROW BELOW CURRENT ROW; IF "WITH DEFAULTS",
DEFAULTS ARE COPIED INTO TOP *TWO* ROWS OF ARRAY. BAD FIX TO
BUG 12268
===============================================================
For versions 4.13/6.01 through 4.15/6.03, INPUT ARRAY improperly
initialized an extra row below the row currently being operated on. The
most visible manifestation of this problem came during INPUT ARRAY (with
defaults) operations; if default values existed in the screen attributes or in
the column defaults as defined using the UPSCOL utility, the user would
be presented with an array that had *two* rows initialized rather than just
one. Each time the user created a new row by any means (e.g. via the INSERT
key or by navigating downward and "creating" a new row below the just-completed
row), that another "phantom row" below the current row would persist. Only
when the user completed the INPUT ARRAY using the Accept key would the
phantom row disappear. This problem has been corrected in the 4.16/6.04
release of 4GL.
36983: GET_FLDBUF DOESN'T RECOGNIZE ALL THE FIELD-NAME VARIANT CASES
IT USED TO
===============================================================
For versions 4.13/6.01 through 4.15/6.03, the internal field-name lookup
mechanism was made more strict than ever before. As with certain
INPUT and CONSTRUCT behaviors (see the note for Bug 45471 on page 10),
get_fldbuf() no longer worked if there was not an exact match between the
field name(s) in the form and the parameter(s) in the get_fldbuf() call.
If a superfluous record name was provided in a get_fldbuf() call, or if a
record name was omitted but the field name was inherently unique, or if
.* was used, it failed. This is fixed so that only those cases
that cannot be resolved due to ambiguity now produce an error.
39848: GET_FLDBUF ON A FORM FIELD THAT HAS BEEN CLEARED RETURNS THE
OLD VALUE THAT WAS IN THE FIELD BEFORE THE CLEAR OCCURRED
===============================================================
CLEARing a form field (using CLEAR or CLEAR FORM) failed to
clear the corresponding zone in the internal query buffer in all versions
prior to the 4.15/6.03 release. This had the following effect: executing
get_fldbuf() on a field that had been cleared could retrieve old data rather
than blanks.
4GL correctly handled fields cleared via CLEAR effective with
the 4.15/6.03 release. The problem with fields cleared via CLEAR FORM
is fixed effective with the 4.16/6.04 release.
41359: P4GL_CALL IS AN UNDEFINED SYMBOL WHEN CREATING A CUSTOM
DEBUGGER. IT IS DEFINED WHEN CREATING A CUSTOM PCODE RUNNER.
=======================================================================
(This in not a bug; what follows is an addendum to documentation on
this subject.)
The method by which you compile a C program that calls a 4GL function,
as indicated in Appendix C of the 4GL Reference Manual, is using c4gl
or fglpc/cfglgo/cfgldb commands. 4GL does not provide any commands or
utilities for creating a customized 4GL Debugger to run a C program that calls
4GL functions; you debug such programs the same way you do regular C
programs, and you cannot step into the 4GL functions.
43144: CAN'T USE LONG CURSOR NAME (18 CAR) WITH 4GL 6.XX, WORKS FINE
WITH FAMILY 4.
================================================================
(This is not a bug; the following information is an expansion upon
information available in earlier release notes.)
Previous release notes (see TOOLREL_4.1 or TOOLREL_6.0, as applicable
for your release) document the -globcurs option but don't fully expand
on its usefulness.
Beginning with version 5.0, the SQL interface which underlies all
INFORMIX tools and embedded languages (ESQL/C) changed its cursor naming
paradigm: cursor names went from being local to a "compilation unit" (module)
to being local to an "execution unit" (i.e. global to a program/process).
4GL has provided a behind-the-scenes mechanism that will, in most cases,
allow 4GL programmers to continue to code as if cursor names were local
to a module; this mechanism involves actually adding characters to the
cursorname to make it unique, then hashing the characters to a smaller
size to remain within the 18-character maximum length.
This will be satisfactory to most users, but it can cause cursor
names that are *not* the same to be reported as if they were duplicates.
This will happen most often when long (18 character) cursor names are used
and are similar except for the last few characters.
In such cases, the -globcurs flag may turn out to be useful. It turns
off the hashing algorithm completely, so that only true duplicates will be
reported as duplicates; however, the cost is that the user must accept
the new paradigm that cursor names are global to a program.
45573: CLIPPED OPERATOR DOES NOT REMOVE TRAILING BLANK SPACES IN
4GL VER 6.02.UC1
====================================================================
When directing report output to a file specified in the "START REPORT..."
or "OUTPUT REPORT TO..." statement, 4GL would truncate any trailing
blanks in the file name specified as the output destination. This
applies to both 4GL and ACE reports. Before this release, the resulting
file name may or may not contain trailing blanks depending on where
the output file is specified.
For example, execution of any of the following statements would result
in a file named "report.out" being created in the current directory:
LET filename = "report.out "
(In 4GL function)
START REPORT rep TO "report.out "
or
START REPORT rep TO filename
(In 4GL report routine)
OUTPUT REPROT TO "report.out "
or
OUTPUT REPORT TO filename
(In ACE report)
OUTPUT REPORT TO "report.out "
44806: ONKEY(RETURN) IS IGNORED UNDER SOME CIRCUMSTANCES, BUT OTHER
KEYS DO MISTAKENLY THIS WHAT RETURN SHOULD DO. ONLY WITHIN:
PROMPT ... END PROMPT
================================================================
Neither RETURN nor CONTROL-K (for UNIX products) should have been
allowed in ON KEY clauses for CONSTRUCT, DISPLAY ARRAY, INPUT, MENU, or
PROMPT. However, attempts to do so were not flagged as errors, and in
some areas of the documentation these were erroneously listed as
acceptable keys for ON KEY. Future documentation will specify that RETURN
and CONTROL-K are not allowed.
45471: ERROR -1129 ON AFTER FIELD CLAUSE USING FORMONLY.
================================================================
Backward-compatibility issue for CONSTRUCT/INPUT SYNTAX: field qualifier
name checking and use of the IXOLDFLDSCOPE environment variable.
Before the 4.13/6.01 release, the syntax
{BEFORE|AFTER} FIELD <.fieldname>
used to run successfully even if the "" name *did not match*
the name of the field qualifier in the form (table name, screen record
name, or the literal "FORMONLY" as applicable).
The fix for bug 12521, introduced in the 4.13/6.01 release, required that
the qualifiers for field names be correct when they were specified by the
4GL programmer so that ambiguous field names could be properly resolved.
As a result, some users' long-working 4GL programs would now terminate
with error -1129 at run time because the qualifier names were stated
explicitly but did not match. Example:
In form:
...
attributes
a = FORMONLY.myfield1;
...
INSTRUCTIONS
SCREEN RECORD f_scrn_rec (FORMONLY.myfield1 THRU FORMONLY.myfieldn)
In 4GL program:
...
DEFINE progrec RECORD ... END
...
INPUT progrec.* WITHOUT DEFAULTS FROM f_scrn_rec.*
AFTER FIELD FORMONLY.myfield1
LET mykeyval = fgl_lastkey()
END INPUT
Note that in the example, the INPUT source uses the screen record as the
qualifier, but the AFTER FIELD clause references the inherent qualifier
"FORMONLY". (Had the fields been based on database columns, the table
name would replace "FORMONLY" in this example.) The field-matching code
for CONSTRUCT/INPUT considers the proper qualifier to be the one given in
the FROM clause; in this case, a mismatch results, and the -1129 error
("Field in BEFORE/AFTER clause not found in form") is issued.
When users encounter this error, Informix recommends that these incorrect
references be corrected. In case doing so presents a significant barrier to
upgrading, a backward-compatible mechanism to disable the qualifier test
has been provided effective with the 4.16/6.04 release.
To activate this backward-compatible (no checking) mode, the user must
set and export the variable name "IXOLDFLDSCOPE" in their environment at
*run time* (not *compile* time). It can be set to any value. Having
IXOLDFLDSCOPE in your calling environment disables the qualifier check.
Note that you lose the benefits of the fix for bug 12521 (for example,
being able to use fields from multiple records in an INPUT statement even
if the same field name occurs in more than one record) while IXOLDFLDSCOPE
is set in your calling environment.
46021: IF 4GL MENU COMMAND STRINGS ARE VARIABLES, '{HIDE|SHOW}
OPTION ""' COMMANDS REQUIRE BLANK-PADDED CONSTANTS
IN VERSION 4.14/6.02 AND 4.15/6.03
===============================================================
There was a minor problem introduced in version 4.14/6.02 which can result
in unwarranted -1168 errors ("Command does not appear in the menu").
If character variables are used for COMMAND strings in MENU statements,
the values of those variables at the time the MENU statement begins are
used as the COMMAND values. This feature allows 4GL developers to precisely
control the run-time appearance of their menu commands.
Any given COMMAND can be made invisible or visible again using the HIDE
OPTION and SHOW OPTION statements. Like the COMMAND statements, HIDE OPTION
and SHOW OPTION accept either character variable name(s) (in which case the
values of those variables are used) or literal strings enclosed in quotes.
If, however, a 4GL program uses literal strings in the HIDE OPTION and SHOW
OPTION statements in the 4.14/6.02 or 4.15/6.03 versions, those literals
must *exactly* match the values in the character strings used in the COMMAND
statements, *including any trailing spaces needed to fill the length of the
character variable*. If they do not, error -1168 is returned, flagging the
MENU statement. This restriction should not have been introduced, and
it is fixed in this release.
Example:
DEFINE menu_opt_1, menu_opt_2, menu_opt_3 CHAR(10)
LET menu_opt_1 = "Item-1"
LET menu_opt_2 = "Item-2"
LET menu_opt_3 = "Quit"
MENU "Test"
BEFORE MENU
HIDE OPTION ALL
SHOW OPTION menu_opt_1 -- This works OK
SHOW OPTION "Item-2" -- This FAILS in the affected versions
-- but works in 4.16/6.04 and above
SHOW OPTION "Item-2 " -- Blank-padding the literal to the
-- full length of the variable used in
-- COMMAND works as a workaround in the
-- 4.14/6.02 and 4.15/6.03 versions.
COMMAND menu_opt_1
COMMAND menu_opt_2
COMMAND menu_opt_3
EXIT MENU
EXIT MENU
48486: NO WAY TO WORK AROUND BUG 31661 FROM WITHIN RDS
PROGRAMMERS ENVIRONMENT
================================================================
(This is not a bug; this is an expansion upon information in previous
release notes.)
In earlier release notes (see TOOLREL4.1 or TOOLREL6.0, as applicable
for your release) the environment variable FGLPCFLAGS was documented. It
can be used to automatically pass optional flags to the RDS compiler
(fglpc) without having to type them on every fglpc command line.
One case where this can prove exceptionally useful is when programs
are being compiled within the RDS Programmer's environment (r4gl). Unlike
the (compiled) INFORMIX-4GL's Programmer's environment, R4gl has no
provision to specify "Compile Options" that can be used by fglpc.
However, the user can use FGLPCFLAGS to pass options such as "-anyerr"
and "-globcurs" to the fglpc compiler.
Be sure to have FGLPCFLAGS set to the desired value *before* entering
the r4gl command; you cannot set FGLPCFLAGS *from within* the RDS
Programmer's Environment.
48766: PICTURE ATTRIBUTE GIVES ERROR 1303 OR 1505 WHEN USING
CONTROL-D OR CONTROL-X
===============================================================
Ignore the section "Editing Keys During Data Entry" from p. 5-49 of
6.0 4GL Reference Manual; CONTROL-D and CONTROL-X editing keys
are not supported in form fields with PICTURE attribute.
52959: RESULT IN ACE REPORT GENERATION, USAGE OF "SKIP TO TOP OF PAGE"
CLAUSE WHEN ALREADY AT THE TOP OF PAGE , SKIPS TO TOP OF *NEXT*
PAGE
===============================================================
The "SKIP TO TOP OF PAGE" clause, in both 4GL and ISQL, was not intended
to be a "SKIP TO NEXT PAGE" functionality. Upon encountering this clause,
the report would skip to the next page if it were not already logically at
the top of a page (disregarding headers), but if the clause when invoked
when the report was already logically at the top of a page, then no action
would be taken.
This avoids the "empty body" syndrome, a problem where pages blank
except for header and trailer information could be issued, seemingly
randomly, within a report. For instance, if an AFTER GROUP BY clause
contained "SKIP TO TOP OF PAGE", and the group had finished printing on
the last line of the previous page so that the report was logically at
the top of the current page, then if the functionality was to skip to the
next page regardless of the content of the body portion of the current
page, the report would issue a page empty of all but header/trailer
content. In contrast, the intended "SKIP TO TOP OF PAGE" functionality
would take no action, preventing a page from being wasted.
However, under some circumstances and in some products, "SKIP TO TOP
OF PAGE" was acting like "SKIP TO NEXT PAGE". The "SKIP TO TOP OF PAGE"
functionality has now been implemented across all products and in all
known situations.
Because some customers have reports that rely on the defective
behavior, there is a new environment variable, "FGLSKIPNXTPG", that will
cause "SKIP TO TOP OF PAGE" to act like "SKIP TO NEXT PAGE". Of course,
users using this new environment variable will be subject to the "empty
body" syndrome described above.
2288: FORM FIELD'S "REQUIRED" ATTRIBUTE IS IGNORED DURING INPUT
WITHOUT DEFAULTS
12854: INPUT ARRAY: BEFORE ROW CLAUSE WORKS INCORRECTLY
18726: SPACES OVERRIDES THE REQUIRED ATTRIBUTE IN FORM ON AN INPUT ARRAY
42524: INPUT ARRAY WITHOUT DEFAULTS AND REQUIRED FIELD. WITHIN THE BEFORE
FIELD STMT BLOCK, LET FIELD EQUAL VALUE. HAVE TO RE-ENTER THE VALUE.
43172: INPUT ARRAY: SATISFACTION OF "REQUIRED" ATTRIBUTE IS NOT PERSISTENT: IT
IS ENFORCED AGAIN IF A ROW IS COMPLETED, LEFT, RETURNED TO, THEN LEFT
AGAIN.
===============================================================
Various fixes affecting usage of the REQUIRED attribute in INPUT and
INPUT ARRAY statements
The bugs listed above are resolved in the 4.16/6.04 release of I4GL.
These are interrelated and are discussed as a group.
For versions 4.13/6.01 through 4.15/6.03, INPUT ARRAY improperly enforced
the REQUIRED attribute in several contexts. The most obvious example was
that if a user had correctly entered a row, satisying all REQUIRED
fields for that row, then navigated the cursor away from that row and later
returned to it, INPUT ARRAY would force the user to re-enter the REQUIRED
fields. These problems are corrected.
To clarify how REQUIRED is processed for each variation of INPUT statement,
the behavior as of the 4.16/6.04 release is documented here.
When a field has a "REQUIRED" attribute, the field is REQUIRED in the
sense that it cannot be simply omitted -- it has to be "satisfied" by
an explicit action. This "satisfaction" can be accomplished in a number
of ways. These include:
- user entry of a non-null value
(blanks are preserved only if WITHOUT NULL INPUT is specified in the form
header and:
a) the corresponding column does not accept nulls, or
b) the column is a FORMONLY column -and- the NOT NULL attribute is
included in the field attributes)
or
- automatic entry of a value using the "DEFAULT=" form attribute
or
- programmatically, by the program explicitly displaying a value to the
field using DISPLAY TO or DISPLAY BY NAME.
If the REQUIRED attribute is satisfied by any of the above means, then it
need not be satisfied again for the duration of that INPUT statement, even
if the value in that field is changed to NULL by later user or program action.
INPUT ARRAY WITHOUT DEFAULTS behaviors:
For INPUT ARRAY WITHOUT DEFAULTS, "initial" rows upon beginning the
statement (the first N rows of the program array, as specified by calling
set_count(N) immediately before the INPUT ARRAY WITHOUT DEFAULTS) are
*exempt* from any REQUIRED checks. The REQUIRED attribute has meaning
*only* for "added" rows -- that is, those rows inserted via the INSERT KEY
or those added to the end beyond the "existing" rows.
For "added" rows, REQUIRED can only be satisfied by either manually
entering a value in the field or if the programmer DISPLAYs a value into
the field.
Once a created row is "completed" (all REQUIREDs and programmatic tests
for that row's fields are satisfied, and the user indicates completion of the
row by moving the cursor off the row using a navigation key or by pressing
the ACCEPT key), the REQUIRED attribute(s) are "satisfied" for that row for
the duration of the INPUT ARRAY statement. (This represents a fix from the
4.15/6.03 release.) In contrast, "initial" rows are completely exempt from
REQUIRED checks -- even if the variable that corresponds to a REQUIRED field
for an initial row is NULL, the REQUIRED test is not applied.
If a value is assigned via a LET statement in a BEFORE ROW clause, that
value is *never* made visible to the user.
If a value is assigned via a LET statement in a BEFORE FIELD clause, that
value is made visible upon the cursor entering that field, but for "added"
rows, it will not satisfy the REQUIRED unless it is also DISPLAYed or unless
the user types a value into the field.
INPUT ARRAY (with defaults) behaviors:
Since all rows are considered "added" rows until they have been completely
entered and the cursor has left the row, the REQUIRED test(s) are applied
for each row during its creation. REQUIRED can only be satisfied by either
manually entering a value in the field or by the programmer DISPLAYing a
value into the field. Once a REQUIRED field has been "satisifed" in this
manner, the REQUIRED check has no further effect; even if the field's
underlying variable's value is changed or a new value DISPLAYED, and
even if that value is NULL or blank, the REQUIRED check is not reapplied.
Once a row is "completed" (all REQUIREDs and programmatic tests for that
row's fields are satisfied, and the row is departed via a navigation key or
ACCEPT key), REQUIRED attribute(s) are "satisfied" for that row for the
duration of the statement. (This represents a fix from the 4.15/6.03 release.)
If a value is assigned via a LET statement in a BEFORE ROW or BEFORE INPUT
clause, that value is *never* made visible to the user until or unless the
cursor traverses that field. If a value is assigned via a LET statement
in a BEFORE FIELD clause, that value is visible upon the user context entering
that field, but it will not satisfy the REQUIRED unless it is DISPLAYed.
INPUT WITHOUT DEFAULTS behaviors:
REQUIRED test(s) are considered unsatisfied if the underlying variable
has a NULL value. Even if a manual DISPLAY has occurred to the field, the
REQUIRED test prevents a NULL value from surviving the validation stage.
This differs from INPUT ARRAY WITHOUT DEFAULTS behavior.
Otherwise, REQUIRED is "satisfied" whether or not the field is traversed
or DISPLAY touches the field. Unlike INPUT ARRAY WITHOUT DEFAULTS, INPUT
does not require a subsequent DISPLAY to make a nonnull value satisfy a
REQUIRED.
If a value is assigned via a LET statement in a BEFORE INPUT clause,
that value is *never* made visible to the user.
If a value is assigned via a LET statement in a BEFORE FIELD clause,
that value is visible upon the user context entering that field.
INPUT (with defaults) behaviors:
REQUIRED test(s) are considered unsatisfied if:
1) the field has not had a value entered by the user -and- has not
been DISPLAYed to, or
2) the underlying variable has a NULL value.
For NULLs, even if a manual DISPLAY has occurred to the field, the
REQUIRED test prevents a NULL value from surviving the validation stage.
This differs from INPUT ARRAY behavior. The fact that a nonnull value
assigned via LET also needs a DISPLAY to satisfy the REQUIRED also differs
from INPUT WITHOUT DEFAULTS (see above).
If a value is assigned via a LET statement in a BEFORE INPUT clause,
that value is *never* made visible to the user.
If a value is assigned via a LET statement in a BEFORE FIELD clause,
that value is visible upon the user context entering that field.
IV. BUGS FIXED IN RELEASE 4.16/6.04
The following bugs were fixed in 4GL
Bug No. Effect Short Description
======================================================================
10379 MALFUN DISPLAY AT CORE DUMPS IN AN ERRONEOUS SITUATION
15096 ERRMSG RUNTIME ERROR 1213 FROM REPORT WITH PRINT COLUMN "TEXT"
25112 MALFUN LINENO NOT ACTING SAME IN RDS AND COMPILED, 1ST LINENO IS 0
AFTER PAGE HEADER IN COMPILED, BUT IN RDS IT IS GETTING SET
TO CORRECT LINE NUMBER
29883 MALFUN BLOB DISPLAY AND INPUT USING A FORM ACTS DIFFERENTLY IN
C4GL AND FGLPC/GO. DISCOVERED 7/25 THAT 29883 OCCURS WITH
BONSAI ALSO
31925 MALFUN CONTROL-O DOES NOT WORK IN AN ON KEY CLAUSE ON A DATA
GENERAL
35959 MALFUN INPUT ARRAY: SPURIOUS SCROLL-DOWN OF PREVIOUSLY DISPLAYED
DATA (FROM FIELD DEFAULTS OR MANUAL DISPLAYS) OCCURS WHEN
INPUT ARRAY TAKES CONTROL
36983 MALFUN GET_FLDBUF DOESN'T RECOGNIZE ALL THE FIELD-NAME VARIANT
CASES IT USED TO
39594 MALFUN USING A RECORD FIELD VAR2.VAR3 AS SELECT STATEMENT VARIABLE
IN AN UNLOAD IN 4GL GIVES SYNTAX ERROR IN FGLC2
COMPILATION
39848 MALFUN GET_FLDBUF ON A FORM FIELD THAT HAS BEEN CLEARED RETURNS
THE OLD VALUE THAT WAS IN THE FIELD BEFORE THE CLEAR
OCCURED
39966 RESULT AN INCORRECT VALIDATE STATEMENT IS NOT CAUGHT BY THE
COMPILER, NOR DOES IT GET DETECTED AT RUNTIME (RETURNS
"VALID" ERROR CODE)
40044 MALFUN USING ERROR ROUTINE DISPLAYS ONLY 79 CHARS - WHERE MESSAGE
DOES 80
40193 CORE I4GL-ID DEBUGGER IS HANGING TERMINAL WHEN DEBUGGING
PROGRAMS ON NCR 3450 USING TABS
40798 COSM ERRATIC CURSOR MOVEMENT WHEN MOVING BETWEEN FIELDS WITH
INPUT STATEMENT AND BEFORE FIELD CLAUSE.
41651 CORE I-4GL COMPILE FAILS WITH MEMORY FAULT ( COREDUMP ) ON
CONSTRUCT STATEMENT THAT REFERENCES DATABASE:TABLE.COLUMN
42072 CORRPT INPUT ARRAY SCROLLS ROW BELOW CURRENT ROW; IF "WITH
DEFAULTS", DEFAULTS ARE COPIED INTO TOP *TWO* ROWS OF
ARRAY. BAD FIX TO BUG 12268
42524 MALFUN INPUT ARRAY WITHOUT DEFAULTS AND REQUIRED FIELD. WITHIN
THE BEFORE FIELD STMT BLOCK LET FIELD EQUAL VALUE. HAVE
TO RE-ENTER THE VALUE.
42906 MALFUN COMPILATION OF A 4GL MODULE WITH A REPORT WITH A LOT OF
PARAMETERS AND VARIABLES FAILS. 1RST PHASE MANGLES THE
PARAMETER NAMES.
43172 MALFUN INPUT ARRAY: SATISFACTION OF "REQUIRED" ATTRIBUTE IS NOT
PERSISTENT: IT IS ENFORCED AGAIN IF A ROW IS COMPLETED,
LEFT, RETURNED TO, THEN LEFT AGAIN.
43190 MALFUN I-4GL LIBRARIES ARE REGARDING INT VARIABLES AS LONG'S,
WHICH IS A PROBLEM ON DEC ALPHA AS AN INT IS 4 BYTES AND A
LONG IS 8 BYTES. RELATED TO B42697.
43973 MALFUN WHEN USING RUN COMMAND IN 4GL DEFUNCT PROCCESSES ARE
CREATED WHICH DO NOT DIE BUT ACCUMULATE
44224 MALFUN IN AN INPUT ... FROM REC.COL1, GET_FLDBUF(REC.*) FAILS WITH
ERROR -1320 THOUGH THE RECORD JUST HAVE ONE COLUMN COL1.
44228 MALFUN IF ERRORLINE AND COMMENT LINE ARE THE SAME. BOTH
ERRORMESSAGE AND COMMENT DISSAPEARS WHEN A KEY IS PRESSED.
ONLY THE ERRORMESSAGE SHOULD DISSAPEAR.
44551 MALFUN FIELD_TOUCHED() SHOWS TRUE FOR REMAINING FIELDS IN ROW IF
ON-KEY CLAUSE BRINGS UP POP-UP WINDOW WITH ANOTHER INPUT
STATEMENT (INPUT ARRAY ONLY)
44734 MALFUN C4GL LOSES TRACK OF DATABASE NAME WHEN GENERATING ESQLC
CODE
44897 MEM GETTING -4339 ERROR : 4GL HAS RUN OUT OF DATA SPACE MEMORY
WHEN CALLING A 4GL FUNCTION FROM A C PROGRAM. (MORE
MANIFESTATIONS OF B39868)
45471 MALFUN ERROR -1129 ON AFTER FIELD CLAUSE USING
FORMONLY. ON 4GL 6.0X
45573 MALFUN CLIPPED OPERATOR DOES NOT REMOVE TRAILING BLANK SPACES IN
4GL VER 6.02.UC1
45841 MALFUN WORDWRAP ONLY DISPLAYS FIRST LINE WHEN USING WORDWRAP WITH
A CONSTRUCT STATEMENT. WORKS FINE WHEN NOT USING A
CONSTRUCT STATEMENT.
45917 MALFUN SKIP TO TOP OF PAGE DEACTIVATED IF IT OCCURS PRIOR TO A
PRINT STATEMENT IN THE ON EVERY ROW CLAUSE (ONLY IF THERE
IS A FIRST PAGE HEADER CLAUSE).
46021 MALFUN IF 4GL MENU COMMAND STRINGS ARE VAR,'{HIDE|SHOW} OPTION
""' COMMANDS REQUIRE BLANK-PADDED CONSTANTS IN
VERSION 4.14/6.02 AND 4.15/6.03
46223 MALFUN GROUP COUNT(*) WHERE FUNCTION IN 4GL REPORT RETURNS BLANK
OR NULL VALUES
47060 CORE CORE DUMP WHEN USING FORM WITH 2 TABLE "JOIN" CODE.
47060 MALFUN CORE DUMP WHEN USING FORM WITH 2 TABLE "JOIN" CODE.
47145 MAINT REGRESSION DUE TO BUG FIX 33743. INCORRECT BEHAVIOUR WHEN
USING SIGNALS
47831 CORE INPUT, INPUT ARRAY WITHOUT DEFAULTS CORE DUMPS WITH
SEGMENTATION VIOLATION
48323 MALFUN DEFINE VARIABLE AS VARCHAR WITH A RESERVE SIZE CAUSING
COMPILE ERROR
52030 MALFUN SCREEN REDRAW PROBLEM: ON SOME TERMINALS, IF ANY CONTENT IS
DISPLAYED IN RIGHTMOST FORM COLUMN (E.G. COL 80),
REDRAWS/DISPLAYS CORRUPTED THEREAFTER
The following bugs were fixed in DEBUGGER
Bug No. Effect Short Description
======================================================================
43929 MALFUN ERROR -16304 WHEN STARTING FGLDB WITH DBMONEY=, AND
INITIALIZATION FILE WITH BREAK
The following bugs were fixed in ISQL
Bug No. Effect Short Description
======================================================================
7587 WKARND UPDATING A RECORD THAT JUST GOT INSERTED CAUSES 3450 ERROR
8534 RESULT PRINTING A BLOB IN A AFTER GROUP BY DISPLAYS A WRONG BLOB
15223 MALFUN MORE THAN 29 SELECT INTO TEMP CAUSES 8018 USING SACEPREP
17433 MALFUN ISQL GOES INTO INFINITE LOOP ON COMMAND LINE OPTION
25553 MALFUN PERFORM LOSES DATA IN 2ND PART OF SUBSCRIPTED FIELD IF 1ST
PART IS NULL
33513 CORE ISQL: CORE DUMP: WHEN TRYING TO UPDATE A LOCKED RECORD
37819 WKARND ACE REPORT WITH MORE THAN 257 COLUMNS OUTPUTS WRONG RESULTS
WHEN USING SELECT *. EXPLICITLY NAMING THE COLUMNS GIVES
CORRECT REUSLTS.
41760 CORE COMPOSITES IN INSTRUCTION SECTION CAUSES CORE DUMP USING
PERFORM
52031 MALFUN SCREEN REDRAW PROBLEM: ON SOME TERMINALS, IF ANY CONTENT IS
DISPLAYED IN RIGHTMOST FORM COLUMN (E.G. COL 80),
REDRAWS/DISPLAYS CORRUPTED THEREAFTER
52959 RESULT IN ACE REPORT GENERATION, USAGE OF "SKIP TO TOP OF PAGE"
CLAUSE WHEN ALREADY AT THE TOP OF PAGE , SKIPS TO TOP OF
*NEXT* PAGE
The following bugs were fixed in RDS
Bug No. Effect Short Description
======================================================================
11760 WKARND FGLGO DISPLAYS ***... FOR VARCHAR FIELD IN 4GL FORM
39296 MALFUN ERROR -4448 WHEN HITTING INTERRUPT ON R4GL RUN PROGRAM
SCREEN. IT TRIES TO RUN NULL PROGRAM ".4GO" AND GENERATES
ERROR
42571 CORE RUN PROGRAM RETURNING INTEGER VALUE DUMPS CORE WITH
SEGMENTATION FAULT
43326 PERF SLOW RDS PERFORMANCE OF SINGLETON SELECTS DUE TO EARLIER
FIX TO B25389
43382 CORE INITIALIZING LARGE NESTED ARRAYS CAN LEAD TO -1326 OR
SEGMENTATION FAULT(COREDUMP). FAILS AT NULLVAR FUNCTION.
46672 MALFUN PROMPT, DISPLAY, ERROR, AND MESSAGE ATTRIBUTES ARE NOT
CONSISTENT OR CORRECT
52370 MALFUN EXECUTING STEP OR CONTINUE COMMAND THE DEBUGGER PUT ISSUES
A "-16338: CAN NOT CONTINUE EXECUTION."
V. KNOWN PRODUCT DEFICIENCIES
There are no known priority 1, 2, or 3 bugs outstanding at code
freeze.
VI. RELEASE NOTES AND NEW DOCUMENTATION
If you are using 4GL Version 4.1X
---------------------------------
If you are using 4GL Version 4.1, you received a supplemental manual
(4GL Supplement) with your product. If your supplement is dated
February 1992 (Rev A), read the release notes for additional
information about the release. (The information in the release notes
does NOT appear in your hardcopy documentation set; it ONLY appears in
the release notes.)
If your supplement is dated June or July 1996 (Rev B), this 4GL
Supplement supersedes the technical information contained in the
release notes. Thus, for technical information, you should use this
supplemental manual rather than the release notes.
In either case, you should continue to use the release notes for
information on bug fixes, outstanding bugs, and the like.
If you are using 4GL Version 6.0X
---------------------------------
If you are using 4GL Version 6.0 AND you have received a supplemental
manual (4GL Supplement) with your product, this 4GL Supplement
supersedes the technical information contained in the release notes.
Thus, for technical information, you should use this supplemental
manual rather than the release notes.
If you are using 4GL Version 6.0 and you have NOT received a
supplemental manual with your product, read the release notes for more
information about the release than is contained in the hardcopy
documentation set. (The information in the release notes does NOT
appear in your hardcopy documentation set; it ONLY appears in the
release notes.)
In either case, you should continue to use the release notes for
information on bug fixes, outstanding bugs, and the like.
