README FILE FOR PRODUCT Pro*COBOL 8.0.5
---------------------------------------
This file contains important information regarding Pro*COBOL Version 8.0.5,
which is the precompiler release corresponding to 8.0.5 Oracle database.
These notes are divided into three sections:
* Section 1 describes compatibility and migration issues that
exist in Pro*COBOL version 8.0.5 with respect to previous versions
of Pro*COBOL.
* Section 2 briefly describes the new feautures introduced in this
release. These features can be classified in two broad categories:
support for migration of DB/2 applications and general improvements.
* Section 3 lists the bugs fixed since Pro*COBOL
Release 2.0.2 (Beta).
* Section 4 lists known restrictions and bugs
in Pro*COBOL 8.0.5.
SECTION 1: COMPATIBILITY & MIGRATION
=====================================
Desupport Notification for V6 Compatibility behavior
----------------------------------------------------
With Oracle7, Oracle offered a Version 6 [V6] Compatibility flag, dbms=v6,
that allowed application developers developing Oracle7 applications to
emulate Oracle6 behavior. With the release of Oracle8.0.3, users are
cautioned that the Version 6 compatibility flag is being desupported
effective immediately in all of the Oracle8 products including PL/SQL8,
all the Oracle Precompilers, the Oracle8 Oracle Call Interface, SQL*Module,
and SQL*PLUS. The desupport of the V6 compatibility flag is consistent with
Oracle's policy of supporting backwards compatibility and behavior from one
version release upgrade to another i.e. from Oracle6 to Oracle7 but not for
more than one version release upgrade.
Specifically, the V6 Compatibility flag emulated the following aspects of
Oracle6 behavior with Oracle7:
o String literals are fixed length in Oracle7 but are treated as variable
length with the V6 flag
o PL/SQL Local char variables are fixed length in Oracle7 but are treated as
variable length with the V6 flag
o Return value of SQL Functions (e.g. USER) are fixed length characters in
Oracle7 but are treated as variable length characters with the V6 flag
o Select/Fetch of a NULL with no indicator raises an ORA-1405 error with
Oracle7 but returns no error with the V6 flag
o SQL group function is called at FETCH time with Oracle7 but is called query
execution time with the V6 flag
o Describe of a fixed length string returns Type=96 with Oracle7 but returns
Type=1 with the V6 flag
All of these behaviors are being desupported with the desupport of the V6
Compatibility Flag with Oracle8.
New default external datatype for PIC X variables
-------------------------------------------------
With Pro*COBOL versions prior to version 2.0.2, the user's PIC X host
variables were mapped to Oracle external datatype VARCHAR2 by default.
With the release of Oracle8.0.2, Pro*COBOL 2.0.2, users are cautioned
that PIC X host variables will now be mapped to the Oracle external datatype
CHARF by default. The new default datatype for PIC X variables affects
the scenario involving varchar2 columns on input. Any trailing blanks which
had formerly been trimmed will be preserved. The PICX option is provided for
backward compatibility. The following table demonstrates the behavior given
the PICX option values and the database column type:
|--------------|-----------------------------------------|
| column | PICX value |
| type | varchar2 charf |
| |--------------------|--------------------|
| varchar2 | trailing blanks | trailing blanks |
| | will be stripped | will be preserved. |
| | on input | |
|--------------|--------------------|--------------------|
| char | strings will be | strings will be |
| | blank-padded to | blank-padded to |
| | width of column | width of column |
| | on input | on input |
|--------------|-----------------------------------------|
The new default affects the case where the user has stored a value with
trailing blanks into a column and then using a PIC X bind variable
initialized with the same value and trailing blanks, selects the value
using the variable in the where clause. If picx=varchar2, there would be
no match due to the fact that the blanks where stripped before the
comparison. Here's the example (ENAME column is VARCHAR2(10)):
...
01 EMPNAME PIC X(5).
01 EMPNAME1 PIC X(5).
...
MOVE "FOO " TO EMPNAME
MOVE "barba" TO EMPNAME1
...
EXEC SQL INSERT INTO EMP (EMPNO, ENAME)
VALUES(1234, 'FOO ') END-EXEC.
...
EXEC SQL SELECT ENAME
INTO :EMPNAME1
FROM EMP
WHERE ENAME = :EMPNAME END-EXEC.
...
The new default also affects the case like that presented in sample9
where the user declares a table of PIC X variables and uses it in a call to
a PL/SQL stored procedure where the PIC X variable gets mapped to an
indexed table of varchar2. Due to the PICX default change, precompiling
sample9.pco without picx=varchar2 now generates the
error:
PCB-S-00576, PLS-418: array bind type must match
PL/SQL table row type
Thus users are now required to precompile sample9
with picx=varchar2.
Extended format of the VARCHAR group item
-----------------------------------------
An extended format of the VARCHAR group item will be recognized as
implicit varchars when option VARCHAR=YES is specified
by the user.
Interaction of options UNSAFE_NULL and DBMS
-------------------------------------------
The interaction of option UNSAFE_NULL and option DBMS will change due to
a new general rule about the interaction of options that control several
functions at once (macro options) and those that control just one
function (micro options). When setting a macro and a micro option, the
user must remember that macro options have precedence over micro options,
if and only if, the macro option is at a higher level of precedence than
the micro option. For more information, please refer to the
"Programmer's Guide to the PRO*COBOL precompiler"
version 2.0 Chapter 7.
SECTION 2: NEW FUNCTIONALITY
=============================
1. Support for Migration of DB/2 Applications.
A significant number of the features of Pro*COBOL 2.0.2 are focused around
providing greater compatibility with DB/2, thereby allowing COBOL
applications developed to work with DB/2 databases to be migrated easily
to work with Oracle. The DB/2 compatibility features
include:
a. Optional Declare Section
Pro*COBOL 2.0.2 supports the ability for the user to declare
host variables of "acceptable type"
outside a Declare Section.
b. Support of additional datatypes
Three additional computational datatypes are supported - COMP-4,
PACKED-DECIMAL, and unsigned comp. COMP-4 will be treated
as a binary datatype, PACKED-DECIMAL will be treated as a COMP-3
datatype, and unsigned comp will be treated as a 2 or 4
byte unsigned integer. Three additional display datatypes are
supported - scaled display trailing, unsigned display, and
overpunch. Also PIC G will be allowed as
the multibyte type PIC N.
c. Support of group items as host variables
Pro*COBOL 2.0.2 supports group items with elementary subordinate items
as host variables in embedded SQL statements. The host group items
can be referenced in the INTO clause of a SELECT/FETCH statement,
and in the VALUES list of an INSERT statement.
d. Extended form of VARCHAR group items
An extended and more flexible format for a COBOL group item to be
recognized as a Variable Length Character Variable (VARCHAR) is
supported.
e. Explicit control over the end-of-fetch SQLCODE value
A command line option is provided for explicit control over the value
returned when the end-of-fetch condition occurs.
f. Support of the WITH HOLD clause in the DECLARE CURSOR statement
DB/2's default behavior is to close all cursors on commit. This can
be overridden on a cursor by using the WITH HOLD clause in the
declaration of the cursor. Pro*COBOL 2.0.2 supports the WITH HOLD
clause in the DECLARE CURSOR statement and also provides
a command line option to allow the user to specify whether cursor
variables without the WITH HOLD clause should remain open or be closed
on commit.
g. Provide DSNTIAR
DB/2 provides an assembler routine called DSNTIAR to obtain a
displayable form of the SQLCA. Pro*COBOL 2.0.2 provides DSNTIAR.
h. Explicit control over DATE string format
A command line option is provided for the user to specify the date
string format.
2. Other general improvements
a. Support for Nested Programs
Pro*COBOL 2.0.2 allows nested programs with embedded SQL
within a single source file.
b. Improved error reporting
Errors will be associated with the proper line in any list file
produced or in any terminal output. "Invalid host variable" errors
will clearly state why the given COBOL variable is invalid for use
in embedded SQL.
c. Support for using REDEFINES clause with group items
The REDEFINES clause is allowed to redefine group items and be used
in host variable declarations.
d. Support for FILLER
The word FILLER is allowed to be used in
host variable declarations.
e. New default datatype for PIC X
The default datatype for PIC X variables has changed from
VARCHAR2 (1) to CHARF (96). A new precompiler option is provided
for backward compatibility.
f. Support for NCHAR data
NCHAR data is now fully supported by the kernel. Previous
releases of the precompiler supported this datatype with the
NLS_LOCAL option. For new applications, users are strongly
encouraged to rely on the database support and accordingly
set NLS_LOCAL=NO during precompilation.
SECTION 3: Bugs Fixed since Release 2.0.2 (Beta):
=================================================
447329 Use of a COPY statement in a declaration resulted in spurious errors
being reported.
447332 Use of variables beginning with digits or containing hyphens in
ARRAYLEN statements resulted in spurious
syntax errors.
447337 Pro*cobol 2 error message 232 pointed to the beginning of the sql
statement instead of the host variable.
447340 Some Oracle extensions such as VARYING and implicit host variables,
EXEC ORACLE statements, and ARRYLEN statements were not fips flagged
when the user specified fips=yes.
447351 The following conditions should have been flagged as errors or
warnings, but were not:
1) The dimension variable of an ARRAYLEN statement is required to
be a 4-byte size of integer (binary) variable.
2) The same variable cannot be used as both a host variable and
an indicator variable within the same SQL statement or
PL/SQL block.
3) Using an ARRAYLEN variable in a SQL statement should have
resulted in a warning.
4) The MAXLITERAL option cannot be used after an EXEC SQL, IAF,
or TOOLS statement.
5) SQL identifiers used in an EXEC SQL EXECUTE statement that
were not first DECLAREd or PREPAREd should have gotten
errors.
6) Indicator variables cannot be used in EXEC IAF statements.
7) An EXEC SQL WHENEVER SQLWARNING statement was used when
MODE=ANSI, but the SQLCA was not
included.
453141 Pro*COBOL did not change comp-4 to comp-5 when option comp5=yes was
specified.
454113 Pro*COBOL seg faults precompiling multi-byte programs using string
literals in Dynamic SQL. It makes no difference whether the string
literals themselves contain multi-byte characters or single-byte
characters.
454277 Pro*COBOL did not set an exit code when done with precompilation. This
would result in "make" scripts continuing with a COBOL compilation and
possibly going through to the link stage, even if an error occurred
during precompilation.
454749 The Pro*COBOL precompiler did not release all memory to the
operating system upon termination. On systems that do not
automatically recover memory when a process terminates,
doing many precompilations could result in all of the system
memory being used up.
454796 The PARTITION clause on a table name was not accepted. The clause
can be used in insert, update, delete, lock table, and select DML
statements.
454801 'WITH READ ONLY', 'WITH CHECK OPTION' were
not accepted in a subquery.
456419 Pro*COBOL did not allow a string after the keyword COPY and not all
forms of the REPLACING clause were allowed.
456425 ROWID was not allowed in select statement.
458644 ARRAYLEN statement did not allow quailified names in the table
field name and the dimension name. Now, the following is allowed
EXEC SQL ARRAYLEN GRP-VAR.TABLE-FIELD (GRP-VAR2.DIMVAR)
END-EXEC.
460295 Precompilation of a non-existant file gave assertion PGE 90104 and
Pro*COBOL error PCB-I-556, besides the expected
PCB-S-104 error.
461435 Use of COBOL variable names containing "-" as a descriptor resulted
in spurious syntax errors during precompilation.
461614 Use of hint comments resulted in spurious
errors at runtime.
462650 The precompiler generated bad code if the first declaration in the
WORKING-STORAGE SECTION had a sequence number
in columns 1 to 6.
462762 Subqueries and table aliases were disallowd simultaneously in the
delete/update dml statements. The following were not allowed
and produced errors (precompile or runtime):
exec sql delete (subquery) <alias> ..
exec sql insert into (subquery) subquery...- <alias> not allowed
exec sql update (subquery) <alias> set ..
exec sql delete <table> <alias> ..
exec sql update <table> <alias>
..
467940 Spurious syntax errors occurred when ".." were used in embedded
PL/SQL.
468121 The precompiler did not terminate immediately when the USERID option
was used and was unable to connect. Instead the precompiler would
proceed with the precompilation and would
give many spurious errors.
469446 Syntax error messages did not display tokens
as actually used.
469449 Pro*COBOL did not support the ALTER AUTHORIZATION clause in
the CONNECT stmt. The clause is now supported at the end of the
connect statement and it has the syntax:
alter authorization :hv
where hv is a host variable.
469468 Originally, Pro*COBOL would always generate 'START WITH' followed
'CONNECT BY' even if the 'CONNECT BY' appeared first. This
would cause problems if the statement was a prepared statement
subsequentally used with an explicit cursor. The resulting
'OPEN USING <bind variable list> would hence sometimes result
in the bind variables being in the wrong order because the
statement was generated in the opposite order. This would cause
runtime type mismatch errors during execution
of the program.
470161 On some platforms, declarations generated to replace pseudo-types
VARYING and SQL-CONTEXT were generated with "COMP5" instead of
"COMP-5".
472605 The equivalencing of group items (when varchar=no) and of implicit
varchars (when varchar=yes) was not handled
correctly.
473530 EXEC SQL VAR did not equivalence some types
properly.
473568 Bad code was generated for PREPARE <statement-id>
FOR <SQL-text>.
473574 No error was generated when an OPEN <cursor> USING statement was
used and the cursor was not for a PREPAREd
dynamic SQL statement.
475242 Bad code was generated when the same host variable was used more than
once in the same PL/SQL block.
477593 Bad code resulting in COBOL compilation errors was generated when an
ANSI mode program using the SQLSTATE status variable and not using
a SQLCODE status variable or the SQLCA was
precompiled.
480940 Pro*COBOL generated extra if statements for some EXEC SQL statements
even when the WHENEVER conditions were not applicable. For example,
the if statement corresponding to whenever not found was begin
generated for the commit statements.
483749 A syntax error was given when the EXEC SQL INCLUDE had a filename
with a dash (i.e. '-') in it.
485650 Using COBOL list control statements EJECT, SKIP1, SKIP2, SKIP3, and
TITLE resulted in spurious errors during
precompilation.
487458 An EXEC SQL INCLUDE statement outside of WORKING-STORAGE or the
PROCEDURE DIVISION would result in spurious syntax errors during
precompilation.
495491 Source lines longer than IRECLEN usually
resulted in spurious errors.
495503 A line with a "--" style comment followed by a line with something
in the sequence field would result in spurious syntax errors during
precompilation.
496227 Pro*COBOL sometimes generated incorrect code resulting in spurious
errors at runtime when a sequence (qualification) was used within
a SQL statement. Also, using a database link ("@" qualification
would result in a spurious syntax error during
precompilation.
496783 Opening a cursor with a FOR UPDATE OF clause can get a spurious
ORA-904 error at runtime.
500353 A segmentation fault could occur during precompilation if there was
a PREPARE USING or EXECUTE USING dynamic SQL statement that was not
preceeded by any executable SQL statement.
Bugs fixed in 8.0.4
-------------------
221157 Memory errors were received when unaligned indicator variables
were used in INSERT or UPDATE statements or in any WHERE clause.
Indicator variables are unaligned when declared in a group item
and the total length of the previous elements in the group item
is an odd number of bytes.
286765 When binding host arrays to PL/SQL tables through dynamic SQL, runtime
errors would result.
344346 When requesting the help screen, precompiler would loop infinitely
for certain NLS languages in which the description of the
command line option was excessively long, without intervening spaces
so much so that it could't fit on a single line without being
broken up into multiple lines.
When requesting the help screen, precompiler will loop when displaying
a message without spaces whose length is a multiple of 48 bytes.
369858 This is actually correct behavior, and LITDELIM should NOT be
allowed as INLINE. With this FIX, it will give a WARNING to
user that this OPTION is NOT legal as EXEC ORACLE OPTION.
The actual error message will be displayed as:
EXEC ORACLE OPTION (LITDELIM=APOST) END-EXEC.
.............................................^
PCC-W-0028: Option "litdelim" not legal as EXEC ORACLE OPTION
467646 Memory leak when a separately precompiled source file contains no
bind/define variables.
475842 Programs using COMP-1/COMP-2 as Host variables DONOT work
correctly with NEC compiler. The built executables cannot
fetch correct data. Also, the definition of COMP-1 and COMP-2
for NEC COBOL85 is different from other platforms. COMP-1 is
in 2 bytes binary format (like a short) and COMP-2 is in 4
bytes binary format (like a long). Changing from S9(4) to
COMP-1 or S9(9) to COMP-2 improves the performance. Because
PIC S9(4), S9(9), COMP-1 and COMP-2 are same data type on NEC
and the length for COMP-1 and COMP-2 is defined to be 2 or 4
bytes so it's simpler than variable length binary data type
PIC S9(4) or S9(9).
513346 An OCCURS clause that was placed at the end of a declaration and which
did not use the TIMES keyword resulted in bad generated code,
resulting in COBOL compilation errors.
513360 Host variables of particular types were shown as invalid in the XREF
and no type was shown, although the host variables were completely
valid.
515388 Pro*COBOL would get a segmentation fault when the last line of a
source file was an EXEC SQL INCLUDE of another source file.
523686 Using an EXEC ORACLE IFDEF statement in the ENVIRONMENT division
caused statements that were otherwise acceptible to Pro*COBOL to
get syntax errors.
533222 Sometimes error messages generated by the precompiler were not put
into the list file. This would generally occurred if there were more
than 255 lines between error messages or between the last error
message and the end of the source file.
533231 When the MAXLITERAL option was used inline is the source code
Pro*COBOL issued an error message, although this should have been
a warning message.
544803 A problem occurred when COPY statements followed END-EXECs
545435 A core dump occurred then the fetch statement physically preceeded
the open statement in a source file.
546237 Get ORA-1017 when connect to database with embedded db name in
username
547565 Pro*COBOL would hang when IRECLEN was exceeded.
548201 No error message was issued when an EXEC statement began in Area A.
549767 "ID" was not acceptted in place of keywordd "IDENTIFICATION".
549835 The INDEXED BY subclause was not allowed before the ASCENDING/
DESCENDING subclause in the OCCURS clause.
550512 Qualified host variables, such as EMP-TABLES.EMP-NAME, were not
being allowed in embedded pl/sql.
553884 COPY statements with file names that have extensions, such as .CPY,
resulted in spurious syntax error messages from the precompiler.
557123 Qualified identifiers were not being allowed in the ASCENDING/
DESCENDING subclause of the OCCURS clause. For example, a
syntax error was being given on:
01 EMP-REC-TABLES.
05 EMP-NUMBER OCCURS 5 TIMES
DEPENDING ON COUNTER
ASCENDING KEY IS BINKEY
OF EMP_REC_TABLES. <-- qualification that caused
syntax error
562185 An error occurred when the user included an unquoted filename
with an extension. For example,
EXEC SQL INCLUDE FOO.CPY END-EXEC
generated an error while
EXEC SQL INCLUDE 'FOO.CPY' END-EXEC
did not.
562244 INCLUDE was not accepted as a precompiler option within source code.
565093 Pro*COBOL produced a syntax error when the user declared a variable
with OCCURS n TIMES DEPENDING ON syntax. Please note that using
a variable declared with OCCURS DEPENDING ON clause in embedded
sql will result in a precompile time error in 8.0.5 onwards.
In 8.0.4, the error will not be produced but unreliable output
will be produced. User's are here then forwarned about this.
571777 An error was produced when FALSE was used in the VALUE clause
of a variable declaration.
573608 Pro*COBOL gave spurious syntax errors whenever a string literal was
used in an END PROGRAM statement.
Bugs fixed in 8.0.5
-------------------
549812 Pro* core dumped when three or more names(e.g., x x x) were given as
file names. When Pro* processes command line options, it expects one
input file name and one output file name. Pro* has been modified to
allow more than two filenames on command line with the appropriate
error message.
553658 Core dump was seen on NT platform with an application that used the
precompiler options nls_char and nls_local. In NT multi-threaded
applications the global runtime context did not get correct
nls_char and nls_local information, leading to a core dump.
571775 Syntax error was produced when the REPLACE function was used in
an embedded sql statement.
573598 Syntax error was produced when source file contained CONSTANT SECTION
in the DATA DIVISION.
583044 VARCHAR host variables in CALL statements were not properly expanded
and were eliminated by the optimization process
of the COBOL compiler.
This resulted in incorrect execution of SQL statement.
586092 Pro*COBOL gave spurious undeclared cursor identifier errors on
cursors declared within a nested program.
598203 Using command line option LTYPE=NONE did not completely suppress
the precompilation list file. The list file created would contain
the cross-reference and option list even with LTYPE=NONE.
598204 Pro*COBOL gave undeclared SQL identifier errors on valid SQL
identifiers when XREF=NO.
599284 Syntax errors were being produced on declaration that contained
'&' in the values clause. For example:
01 USERNAME PIC X(10) VALUE "SCO"
& "TT".
606918 Pro*COBOL generated incorrect code for VARYING variables when an
element of the generated group item exceeded one line. In a
multi-byte environment, the line break could have occurred between
bytes of a multi-byte character, causing
compile time errors.
610739 Pro*Cobol did not recognize <= if there was a space between < and =.
Pro*Cobol now skips the space when processing <=. A similar
change is made so that space in >=, <>, !=, ^= is also accepted.
611974 Host variable names in an INTO clause that were not prefixed by a
colon were treated as SQL identifiers by Pro*COBOL. Since SQL
identifiers cannot contain hyphens, Pro*COBOL gave spurious errors in
this situation when the host variable name contained any hyphens.
612519 'SELECTION' is changed to 'INEMPNO' as a proper meaningful name
in sample4.pco
622811 A memory leak occurred when a cursor was
closed.
629475 Certain Cobol compilers (e.g. NEC) do not accept PIC clause together
with the usage of COMP-1 or COMP-2. Pro*COBOL was generating some
temporaries with "PIC S9(4) COMP-1", giving compiler errors on some
Cobol compilers.
629943 As per ANSI standard, OCCURS clause cannot be used at level 01.
Pro*COBOL generated a few temporary variables at level 01 with an
OCCURS clause, causing compilation error on some strict ANSI compliant
compilers (like DEC Cobol compiler).
631374 Could not use implicit varchar host variables due to incorrect
generated code or precompile time error.
For example,
01 EMPNAME.
49 EMPNAME-LEN PIC S9(4) COMP.
49 EMPNAME-ARR PIC X(10).
when used in
EXEC SQL CONNECT :EMPNAME IDENTIFIED BY :PASSWD END-EXEC.
generated precompiler error (using option varchar=yes)
PCB-S-00208, Incorrect type for host variable "EMPNAME"
When the same implicit VARCHAR is used in non-CONNECT statement,
such as,
EXEC SQL
SELECT ENAME INTO :EMPNAME FROM EMP
WHERE EMPNO = 7788
END-EXEC.
and precompiled with the option varchar=yes, it generated incorrect
code as:
CALL "SQLADR" USING
EMPNAME-LEN
SQL-SQHSTV(1)
Following correct code is now being generated:
CALL "SQLADR" USING
EMPNAME-LEN IN
EMPNAME
SQL-SQHSTV(1)
636325 Before 8.0.4, one could use the EMBEDDED SQL CONNECT statement to
connect to user SYS identified by the password CHANGE_ON_INSTALL
with SYSDBA privileges by default as:
EXEC SQL CONNECT :uid IDENTIFIED BY :pwd;
In 8.0.4, the same EMBEDDED SQL CONNECT statement above would fail,
because it required the user to specify the connection mode. In
8.0.5 Pro*COBOL the new EMBEDDED SQL CONNECT syntax allows the user
to specify the connection mode:
EXEC SQL CONNECT :uid
[IDENTIFIED BY :pwd]
[AT [:]dbname [USING :hst]]
[ALTER AUTHORIZATION :newpw] | [IN {SYSDBA|SYSOPER} MODE]
Restriction:
It is not possible to connect in SYSDBA/SYSOPER mode when using
the auto_connect feature.
642112 When a connection was not made through an EMBEDDED SQL CONNECT
statement, sqllib returned ORA-01012 error message.
SECTION 4: KNOWN RESTRICTIONS AND BUGS IN PRO*COBOL 8.0.5
=========================================================
Below is a list of the known restrictions imposed by the new features
in Pro*COBOL 8.0.5:
- Restriction on the use of the DATE_FORMAT option:
All compilation units to be linked together must use the same DATE_FORMAT
value.
- Restriction on the support of nested programs:
Recursion with nested programs in not supported.
- Support of the REDEFINES clause:
A single INTO clause which uses items from both a group item host variable
and from its redefinement should be avoided.