HP 3000 Manuals HP 3000 Manuals
All Programming Languages
General guidelines for all languages supported include the following:
* 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.