All Programming Languages

Create and use message catalogs. Do not hard-code any text messages, including prompts. For example, never require a hard-coded Y or N in response to a question. The equivalents of YES and NO for every language supported by NLS are available through a call to NLINFO item=8.

Use the NLS date and time formatting intrinsics. Do not use the MPE XL intrinsics DATELINE, FMTCLOCK, FMTDATE, and FMTCALENDAR. They all result in American-style output.

Check a character's attribute, available through NLINFO item 12, to determine printability. Alternatively, use the NLREPCHAR intrinsic to check whether the character gets replaced or not. Do not use range checking on the binary value of a character to decide whether it is printable or not.

Use the NLCOLLATE intrinsic to compare character strings. Do not compare character strings (IF abc > pqr... , where abc and pqr are both character strings). Since these comparisons are based on binary values of characters as they appear in the USASCII sequence, they usually produce incorrect results. Obviously, this is not applicable in case an exact match is tested (IF abc = pqr ... ).

Use NLSCANMOVE for upshifting and downshifting. Do not upshift or downshift based on the character's binary value. For a-z in USASCII, upshifting can be done by subtracting 32 from the binary value. This does not work for all characters in all character sets.

To determine whether a character is uppercase or lowercase, use the character attributes table available through NLINFO item=12. Do not use a character's binary value in range checks to decide whether it is an uppercase or lowercase alphabetic character.

Most Hewlett-Packard and user-written software assumes that numeric characters (0 through 9) are represented by code values 48 through 57 (decimal). In general, this is valid because standard Hewlett-Packard 8-bit character sets are supersets of USASCII. However, some character sets may have different or additional characters that should be treated as numeric. Therefore, if at all possible, avoid doing range checks on code values to recognize or process numeric characters. For recognition of numeric characters, interrogate the character attributes table, available through a call to NLINFO item=12.

Use the NLTRANSLATE intrinsic, not CTRANSLATE, to translate to or from EBCDIC.

Do your own formatting using the decimal separator, the thousands separator, and the currency symbol available through NLINFO item=9 and 10. Use the standard statements to output into a character string type variable. Replace the decimal and thousands separators by those required in the language being used. Do not use standard output statements (PRINT, WRITE) for real numbers, since this formats them according to the definition of the programming language. This usually results in American formats with a period used as the decimal separator.

Input data into a character string, and preprocess the string to replace any decimal or thousands separators used in the American formats. Then supply the string to the standard READ statement. Standard input statements for real numbers (READ, ACCEPT) should not be used, as they accept the period as the decimal separator. Many non-American users input something else (for example, a comma).

Always store standard formats for date and time (like those returned by FMTCALENDAR and FMTCLOCK) if dates or times have to be stored in files or databases. Never store a date or a time in a local format. Intrinsics are available to convert from the standard format to a local format, but the reverse is not always possible.

Use VPLUS/XL local edits. VPLUS/XL edit processing specifications and terminal edit processing statements are separate and are not checked for compatibility. There is no check specified as a terminal local edit consistent with the language-dependent symbol for the decimal point (DEC TYPE EUR, DEC TYPE US) in the configuration phase.