Variant and Invariant Characters
As you learned in the first article, the iSeries (AS/400) supports many different code pages, character sets, and CCSIDs. The integration of all these code pages makes national language support a complex subject. To make things a little easier, IBM introduced a special set of characters known as the invariant character set. The invariant character set is a subset of the most commonly used characters. Each character in the invariant set has the same code point across the majority of EBCDIC pages. The invariant set does not cross from EBCDIC to ASCII, as they are entirely different encoding schemes.This means that the letter A, for example, is located at code point X'C1' in all of the EBCDIC pages. Figure 1 lists the characters in the invariant character set.
0 1 2 3 4 5 6 7 8 9
% & * ( ) - _ = + '
" ; : . > "," < ? /
a b c d e f g h i j
k l m n o p q r s t
u v w x y z
A B C D E F G H I J
K L M N O P Q R S T
U V W X Y Z
Figure 1: Characters in the invariant character set have the same code point across most EBCDIC code pages.
As with any rule, there are exceptions. The following EBCDIC code pages do not implement the entire invariant character set:
· 290 Katakana
· 290 Japanese (Katakana) Extended
· 420 Arabic Bilingual
· 905 Turkey Extended
· 1026 Turkey
It stands to reason that if there are invariant characters, there must also be variant characters. Variant characters are characters that are either not in all of the code pages or that have varying code points across code pages. Another way to look at it is that certain (variant) code points will represent different characters in different code pages. For example, code point X'7C' represents the at symbol (@) in code page 37, but it represents the Danish character "?" in code page 277. It is important to be aware of the characters in the invariant character set, because program constants should only contain invariant characters. This warrants further discussion.
Program Constants
One of the most common CCSID-related programming mistakes is hard-coding constant values into program source. Hard-coded constants include not only fields defined as a constant data type, but also values that are placed directly in assignment or condition statements. For example, in the RPG excerpt in Figure 2, the pound sign (#) and ABC are both constants. The pound sign is a declared constant and the ABC is an implicitly declared constant. Although the example is in RPG, this applies to all programming languages on the iSeries, as well as display and printer files.
|
Figure 2: The second If may fail, even if var2 contains a pound-sign character (#).
Constants are stored in the program object as hexadecimal values. When the program is created, the constants are converted to hex using the CCSID of the job. This is probably not a problem when the constant values are in the invariant character set. However, if the values are variant characters, watch out!
In Figure 2, the ABC is not a problem because A, B, and C are all in the invariant character set. The pound sign, on the other hand, is not. Assume this program is created on a system with CCSID 37; the pound sign actually gets stored in the program object as X'7B'. When this program is run on a system with CCSID 277, the second IF statement will not evaluate properly, as const1 will be considered as the symbol ? (code point X'7B' on CCSID 277) rather than as a pound sign. This is probably not the expected result.
Perhaps the best way to solve this problem is to use only those characters that are in the invariant character set. The reason for this is that some of the characters outside the invariant set do not exist in all code pages. If the character does not exist in the target CCSID, OS/400 performs a character substitution. The substitution thereby creates a data integrity problem, and programs may not operate as expected.
For those instances when a variant character must be used, such as an at symbol (@) for email addresses, simply placing the constant values in an external file that has a CCSID other than 65535 will do the trick. When the program initializes, have it load the constant values from the file into variables. Returning to the previous example, assume the constants are stored in a file with a CCSID 37 and the program is running under CCSID 277. When the program loads the data, the system realizes that the CCSID of the job is 277 and the object being read is 37; it then converts the data from 37 to 277. Thus, the X'7B' stored in the file gets converted to X'4A' (the code point for the pound sign on CCSID 277) before it even gets loaded into the program variable. Voil
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online