topic Re: Silly DCL question in Operating System - OpenVMS

Silly DCL question

Jimson_1 — Thu, 30 Oct 2008 11:11:22 GMT

Hi,

Silly question here...
And all because I need to justify my review comments on some DCL script that someone changed...

In DCL, why bother having the comparison operators .ne. and .nes. when DCL converts everything to the same type before the comparison anyway?

For example, all the following work:

$ IF 1 .EQS. "1" THEN WRITE SYS$OUTPUT "EQUAL"
EQUAL

$ IF 1 .EQ. "1" THEN WRITE SYS$OUTPUT "EQUAL"
EQUAL

$ IF "1" .EQ. 1 THEN WRITE SYS$OUTPUT "EQUAL"
EQUAL

$ IF "1" .EQS. 1 THEN WRITE SYS$OUTPUT "EQUAL"
EQUAL

Re: Silly DCL question

Hein van den Heuvel — Thu, 30 Oct 2008 11:23:54 GMT

Try

$ IF 01 .EQ. "01" THEN WRITE SYS$OUTPUT "EQUAL"

vs

$ IF 01 .EQS. "01" THEN WRITE SYS$OUTPUT "EQUAL"

hth,
Hein.

Re: Silly DCL question

Jimson_1 — Thu, 30 Oct 2008 13:00:10 GMT

Excellent.
Thanks.
Unfortunately I can only give you 10 points.
You deserve twice as many.

Regards

JamesP

Re: Silly DCL question

Jess Goodman — Thu, 30 Oct 2008 14:32:25 GMT

Another example showing what can happen if you use the wrong comparison operator:

$ IF "abcdef" .eq. "GHIJKL" THEN WRITE SYS$OUTPUT "same string"
same string

Re: Silly DCL question

Jimson_1 — Thu, 30 Oct 2008 14:38:31 GMT

Thanks, any more examples?

Re: Silly DCL question

John Gillings — Fri, 31 Oct 2008 01:15:05 GMT

JamesP,

Not a silly question at all!

Jess's example shows a very common error in DCL code. I've been bitten by that one many times!

"when DCL converts everything to the same type before the comparison anyway?"

This is the source of the trouble! It doesn't convert to a common type, instead it trys to guess the approprite typefor each symbol from context. Implicit conversions can, and often do guess the wrong thing and give unexpected results. (try Basic sometime - a simple line of code can often generate a bewildering number of unexpected conversions). Another place this causes trouble in DCL is in string arithmetic:

$ x=1
$ s1="A"
$ s2="B"
$ s3=s1+s2
$ s4=s1+s2+x

The presence of a single numeric symbol changes the whole expression to numeric, so the value of s4 is (numeric) 1.

I find it safer to make all conversions explicit, using F$INTEGER and F$STRING in anything but the most simple instances. Code is more verbose, but also more robust.

Re: Silly DCL question

Jess Goodman — Fri, 31 Oct 2008 14:36:15 GMT

John,

I find that using F$INTEGER(SYMBOL) in an expression (instead of just SYMBOL) is pointless, because F$INTEGER does not give an error if SYMBOL is not a numeric string.

Just like an implicit conversion, F$INTEGER converts non-numeric strings to either 0 or 1 based on the first character.

So instead of code like this:
$ I = F$INTEGER(INPUT)

I use:
$ I = 'INPUT'
which at least gives a warning message on non-numeric strings (assuming the value of INPUT is not a symbol name). That way you can eveen test if the conversion failed with:
$ IF (.NOT.$STATUS) THEN SAY "bad input"

Of course even better code would be to first test using F$TYPE(INPUT) and then convert it, but that is an extra step to add to the code.