=head1 README.vms.txt for DBI and DBD::Oracle
Date: Wed, 15 Sep 2004 11:44:09 +0300
From: Jakob Snoer <firstname.lastname@example.org>
This is related to Oracle RDBMS 9.2 and later, since Oracle
made fundamental changes to oracle installation requirements
and factual installation with this release.
Oracle's goal was to make VMS installation be more like on
*nix and Windows, with an all new Oracle Home structure too,
requiring an ODS-5 disk to install Oracle Home on instead of
the good old ODS-2.
Another major change is the introduction of an Oracle generated
logical name table for oracle logical names like ORA_ROOT and all
its derivatives like ORA_PROGINT etc. And that this logical name
table is inserted in LNM$FILE_DEV in LNM$PROCESS_DIRECTORY.
"LNM$FILE_DEV" = "SERVER_810111112"
This ensures that any process that needs to have access to
oracle gets the environment by just adding one logical name table
to a central process specific mechanism.
But as it is inserted at the very top of LNM$FILE_DEV it also
represents a source of misfortune - especially if a user with
enough privilege to update the oracle table does so (presumably
unintentionally), as an examble by changing NLS_LANG.
PERL has the abillity to define, redefine and undefine (deassign)
logical names, but if not told otherwise by the user does it
in the first table in above list, and not as one would normally
expect in the process table.
Installing DBI and DBD::Oracle has influence upon this since in
both cases a few enviroment variables are read or set in the
For DBI it is the logical SYS$SCRATCH, which is a JOB logical.
For DBD-Oracle it is when testing a new feature in the Oracle
RDBMS: UTF8 and UTF16 character set functionallity, and in order
to do this it sets and unsets the related environment variables
NLS_NCHAR and NLS_LANG.
If one is not careful this changes the values set in the oracle
table - and in the worst case stays active until the next major
system reset. It can also be a very hard error to track down
since it happens in a place where one normally never looks.
Furthermore, it is very possibly that some or all of the UTF tests
fails, since if one have a variable like NLS_LANG in his process
table, then even though 'mms test' sets it in the wrong table
it is not invoked as it is overruled by the process logical...
The way to ensure that no logicals are set in the oracle table and
that the UTF tests get the best environment to test in, and that
DBI correctly translates the SYS$SCRATCH logical, use the
to ensure that PERL's behavior is to leave the oracle table alone and
use the process table instead:
$ DEFINE PERL_ENV_TABLES LNM$PROCESS, LNM$JOB
This tells PERL to use the LNM$PROCESS table as the default place to
set and unset variables so that only the perl users environment
is affected when installing DBD::Oracle, and ensures that the
LNM$JOB table is read when SYS$SCRATCH is to be translated.
PERL_ENV_TABLES is well documented in the PERLVMS man page.
Oracle8 releases are not affected, as they don't have the
oracle table implementation, and no UTF support.
Oracle 9.0 is uncertain, since testing has not been possible yet,
but the remedy will not hurt :)