DBD::Oracle::Troubleshooting::Vms - Tips and Hints to Troubleshoot DBD::Oracle
This is related to Oracle RDBMS 9.2 and later, since Oracle made fundamental
changes to oracle installation requirements and factual installation with this
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
"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
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 example by
PERL has the ability 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
environment variables are read or set in the test phase. 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 functionality,
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
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 logical
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 :)
- Tim Bunce <firstname.lastname@example.org>
- John Scoles <email@example.com>
- Yanick Champoux <firstname.lastname@example.org>
- Martin J. Evans <email@example.com>
This software is copyright (c) 1994 by Tim Bunce.
This is free software; you can redistribute it and/or modify it under the same
terms as the Perl 5 programming language system itself.