Following post is from:
http://repettas.wordpress.com/2008/05/19/peopletools-84x-unicode-vs-non-unicode-tools-installation/
What’s the difference between a Unicode and non-Unicode Tools install?
SOLUTION:
If UNICODE_ENABLED=1 on the PSSTATUS table, then you definitely have a Unicode
installation. If UNICODE_ENABLED=0, then you do NOT have a Unicode
installation.
COBOL DIFFERENCES
After you enter your PeopleSoft Licence Code during the PeopleTools
installation, there are two radio buttons. You are asked to choose whether the
installation is ANSI or Unicode. If you choose Unicode, a unicode.cfg file is
generated in the %PS_HOME%\setup directory. This file is subsequently sent to
the Unix box during the PeopleSoft Batch Transfer (pstrans.exe).
The COBOL codeline is the same. The only difference is the one file,
unicode.cfg in the \setup directory. This is not found in a non-Unicode
installation. In a Unicode installation, the file has one section [unicode] and
one line, unicode = 1.
This file impacts the compile process of our source COBOL. There is a flag
in the pscbl.mak script which looks for the existence of this file. If it
exists, then an additional script is run to perform the unicode conversion and
compilation.
For NT Customers with unicode db, run CBL2UNI.BAT for any NT Servers which
host the COBOL executables. This also applies to Unix Customers using an NT
Application server to support Remote call COBOL.
NOTE: When running a Unicode database the parameter RCCBL PRDBIN needs to be
set. The line delivered — %PS_HOME%\cblbinU is only an example, itn may not be
your actual path.
Customer used %PS_HOME%/cblbin — NOT %PS_HOME%\cblbinU. No U and / not \.
ISSUE:
Running both Unicode and non-Unicode databases.
When attempting to run a calc from the process scheduler we are getting the
message below. Is it a problem with Server Express, compiled COBOL or something
else?
Error Message : SQLRT: Using Unicode COBOL for an Ansi DB
SOLUTION:
Unicode and non-Unicode installations can not share the same compiled codeline.
The Unicode databases require the COBOL programs to be converted/compiled
appropriately for Unicode.
If each database instance has its own codeline on the Unix box that was
brought over using PSTRANS.exe from the FileServer PeopleTools installation, it
should be possible. If necessary, remove/rename the unicode.cfg file from
$PS_HOME/install in the ANSI environments and re-compile the COBOL.
See also:
Resolution 709697: Remote COBOL program (GLPJEDIT) failed with return code:
9977, Reason: SQLRT: Attempting to use Ansi API for a Unicode DB ;
E-INST Unicode vs. non Unicode. 8.16 Tools
Details: Unicode Databases
In addition to supporting several legacy character sets, PeopleSoft supports
creating Oracle databases using Unicode. Unicode enables you to maintain data
in virtually any modern language in a single database. Prior to Unicode, many
languages could not co-exist in one database, as they did not share a common
encoding scheme.
To create an Oracle Unicode database, the character set UTF8 must be
specified in the CREATE DATABASEstatement. PeopleSoft triples column sizes when
running against a Unicode Oracle database, as all Oracle 8i column sizes are
measured in bytes, and PeopleSoft uses character-based column sizes. This
tripling in size represents the worst-case 1-to-3 ratio of characters-to-byte
for Basic Multilingual Plane Unicode characters when represented in UTF8.
Unicode databases are particularly important if the languages you selected
do not share the same character set. Typically, a single character set can
encode all languages written in a single script. For example, English, French
and Spanish all share the same script (Latin), so they can co-exist in a
non-Unicode database. However, Japanese does not share the same script as
French, so if you need to have Japanese and French co-exist in a single system,
you will require a Unicode database.
Note! The characters required for the English language exist in all Unicode
and non-Unicode character sets, so you can safely disregard English when you
are determining whether to use Unicode for your database. For example, Japanese and English can co-exist in a single Unicode or non-Unicode
database. If you plan on installing or supporting a combination of languages
that do not share the same character set, you should use a Unicode database. On
Oracle, Unicode characters require between 1 and 3 bytes of storage each. As
characters needed to write English are represented with one byte in UTF8, you
should see no additional space requirements for a UTF8 database when using
primarily English characters.If you decide to use Unicode for your database,
you do not need to select a character set as described below.
Non-Unicode Databases
If you plan on running only one language in your system, or if your selected
languages share the same character set, you can safely create a non-Unicode
database. In this case, you need to decide in which character set your database
should be created.
On Oracle, PeopleSoft supports the following Oracle character sets. Should one
or more languages you are planning on using not appear in this list, you will
need to create a Unicode database, as this is the complete list of Oracle
non-Unicode character sets supported by PeopleSoft.
When installing a PeopleSoft unicode database, you will run the rel8xxu.sql
scripts as part of the installation process.
