Posted by: repettas | May 19, 2008

PeopleTools 8.4x Unicode vs. non-Unicode Tools Installation

PeopleTools 8.4x 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.

About these ads

Responses

  1. Thanks a lot for your answer on the forum. It really helped me to resolve a long standing issue.
    :) Thanks much again


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: