Character Strings Interpreted as Numbers
Problem: Errors can occur when numeric operations are applied to character strings
whose first character is a digit or minus sign because PSL will evaluate
these character strings as numbers.
Reason: Before PSL performs an operation, it must determine whether the
operands are numeric or character. To make the determination, PSL
performs one of the following tests:
• For relational operators, PSL tests that both operands consist entirely
of digits, a period, and/or a minus sign. Otherwise, both operands are
character type.
• For arithmetic operators, PSL tests only that the first character of
each operand is a digit or minus sign. Otherwise, both operands are
character type that generates a run-time warning.
The run-time warnings perform the same check as the as arithmetic
operators.
These features remain for compatibility with previous releases of
PATROL.
Arithmetic operators identify the character string “10th May” as the
number 10 while relational operators correctly identify it as a character
string. Its use as an arithmetic operand will not generate a run-time
warning.
Solution: Be aware that character strings whose first character is a valid numeric
representation can cause unexpected results in numeric operations that
will not be detected by PSL diagnostics. Avoid the use of such strings.
Floating Point Numbers Interpreted as Character Strings
Problem: PSL interprets floating point numbers with a leading decimal point as
character strings.
Reason: Before performing a numeric operation, PSL evaluates both operands to
verify that they are numbers. PSL tests only that the first character of
each operand is a digit or minus sign. Upon detecting that the first
character is a decimal point, PSL identifies the operator as a character
string and returns a warning.
PSL identifies the operand 0.33 as a number and the operand .33 as a
character string.
Solution: Begin each floating point number with a digit or a minus sign.
Character Strings Interpreted as Variable Names
Problem: PSL interprets character strings that are not enclosed in double quotation
marks as variable names.
Reason: The PSL language requires that all character strings appearing in
statements and function calls be enclosed in double quotation marks to
identify them as character strings.
Improperly identified character strings will not generate compiler errors
but may generate warnings about uninitialized variables if the string is
not equivalent to a variable name initialized elsewhere in the program.
PSL interprets the statements get(Dev); and get(RDB/Dev); as requests
for the values of the user variables Dev and RDB/Dev. PSL interprets the
statements get("Dev") and get("RDB/Dev") as requests for the PSL
object variables Dev and RDB/Dev.
Solution: Enclose all strings in double quotation marks. Enable PslDebug flag 16
to catch variable names that were not explicitly initialized within the PSL
program.
Problem: PSL interprets character strings that are not enclosed in double quotation
marks as variable names.
Reason: The PSL language requires that all character strings appearing in
statements and function calls be enclosed in double quotation marks to
identify them as character strings.
Improperly identified character strings will not generate compiler errors
but may generate warnings about uninitialized variables if the string is
not equivalent to a variable name initialized elsewhere in the program.
PSL interprets the statements get(Dev); and get(RDB/Dev); as requests
for the values of the user variables Dev and RDB/Dev. PSL interprets the
statements get("Dev") and get("RDB/Dev") as requests for the PSL
object variables Dev and RDB/Dev.
Solution: Enclose all strings in double quotation marks. Enable PslDebug flag 16
to catch variable names that were not explicitly initialized within the PSL
program.
PSL Functions That Do Not Modify Their Arguments
Problem: Some PSL functions do not modify their arguments and their return
values are lost if not explicitly saved in the PSL program.
Reason: Some PSL functions return modified copies of their arguments as return
values, preserving the integrity of the original arguments.
For example, the PSL function call trim(text,"\t"); returns a copy of
the character string variable text with all tab characters removed. Without
an explicit destination and because the trim function cannot modify its
test argument, the return value is discarded before executing the next PSL
statement. Alternately, the PSL function call text=trim(text,”\t”);
returns the modified copy of string variable text and stores it back into
text.
PSL functions that do modify their arguments are those that perform
command execution and PSL object manipulation, including the
following:
• create()
• destroy()
• system()
• execute()
• set()
• log()
• close()
• print()
• popen()
• write()
The return values for these functions generally indicate the completion
status of the operation and may not need to be retained.
Solution: Become familiar with the descriptions of the PSL built-in functions.
Those that return more than a completion status value probably do not
modify their arguments and thus require that you explicitly save the
return value if it is to be available to other statements within the program.
Functions That Do Not Write to the System Console Window
Problem: PSL built-in functions such as grep(), cat(), or get_var() do not
display their return values in the system console window.
Reason: PSL built-in functions return their values to the PSL program. To display
those values outside the program, they must be printed.
For example, grep(), cat(), and get_var() produce no output to the
system console window but print(grep()), print(cat()), and
print(get_var()) will print the specified function return values.
Solution: To display function return values in the system console window, make
those functions arguments of the print() function.