Unicode Migration using National Characterset data types - Best Practice ?

Question

I know that Oracle discourages the use of the national characterset and national characterset data types(NCHAR, NVARCHAR) but that is the route my company has decide to take and I would like to know what is the best practice regarding this specifically in relation to stored procedures.
The database schema is being converted by changing all CHAR, VARCHAR and CLOB data types to NCHAR, NVARCHAR and NCLOB data types respectively and I would appreciate any suggestions regarding the changes that need to be made to stored procedures and if there are any hard and fast rules that need to be followed.
Specific questions that I have are :
1. Do CHAR and VARCHAR parameters need to be changed to NCHAR and NVARCHAR types ?
2. Do CHAR and VARCHAR variables need to be changed to NCHAR and NVARCHAR types ?
3. Do string literals need to be prefixed with 'N' in all cases ? e.g.
in variable assignments - v_module_name := N'ABCD'
in variable comparisons - IF v_sp_access_mode = N'DL'
in calls to other procedures passing string parameters - proc_xyz(v_module_name, N'String Parameter')
in database column comparisons - WHERE COLUMN_XYZ = N'ABCD'
If anybody has been through a similar exercise, please share your experience and point out any additional changes that may be required in other areas.
Database details are as follows and the application is written in COBOL and this is also being changed to be Unicode compliant:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
NLS_CHARACTERSET = WE8MSWIN1252
NLS_NCHAR_CHARACTERSET = AL16UTF16

Answer 1

##1. while doing a test convertion I discovered that VARCHAR paramaters need to be changed to NVARCHAR2 and not VARCHAR2, same for VARCHAR variables.
VARCHAR columns/parameters/variables should not by used as Oracle reserves the right to change their semantics in the future. You should use VARCHAR2/NVARCHAR2.
##3. Not sure I understand, are you saying that unicode columns(NVARCHAR2, NCHAR) in the database will only be able to store character strings made up from WE8MSWIN1252 characters ?
No, I meant literals. You cannot include non-WE8MSWIN1252 characters into a literal. Actually, you can include them under certain conditions but they will be transformed to an escaped form. See also the UNISTR function.
## Reason given for going down this route is that our application works with SQL Server and Oracle and this was the best option
## to keep the code/schemas consistent between the two databases
First, you have to keep two sets of scripts anyway because syntax of DDL is different between SQL Server and Oracle. There is therefore little benefit of just keeping the data type names the same while so many things need to be different. If I designed your system, I would use a DB-agnostic object repository and a script generator to produce either SQL Server or Oracle scripts with the appropriate data types or at least I would use some placeholder syntax to replace placeholders with appropriate data types per target system in the application installer.
## I don't know if it is possible to create a database in SQL Server with a Unicode characterset/collation like you can in Oracle, that would have been the better option.
I am not an SQL Server expert but I think VARCHAR data types are restricted to Windows ANSI code pages and those do not include Unicode.
-- Sergiusz