DCL anomaly

[Willem Grooters]

VMS 7.3-2 - and possibly others (didn't check yet).

If you use a non-existing symbol in a lexical function, DCL will signal an error, but when the same is used in creating a string, it's accepted as an empty string.

DKWS38>sho sym bagger
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
DKWS38>say f$fao ("!AS",bagger)
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
\BAGGER\
DKWS38>say "dit is ''bagger'"
dit is
DKWS38>s="Dit is ''bagger'"
DKWS38>sho sym s
S = "Dit is "
DKWS38>

Sometimes it would be nice if this situation were signalled "Undefined symbol" as well - a typo would less likely be overlooked...

[Bart Zorn_1]

Yes, that would be nice.

As is often the case, it would also break things. For example, SYS$MANAGER:TCPIP$CONFIG.COM uses this "feature" ...

Regards,

Bart Zorn

[Wim Van den Wyngaert]

Willem,

Just use
"This is " + bagger

The syntax you use has for me the advantages :
- auto conversion int to str
- auto test on existance

But be careful :
$ bagger=1
$ write sys$output "This is " + bagger
1

Wim

[Jon Pinkley]

If they changed the behavior now, it would cause things to break.

I believe it existed before the f$type lexical existed.

I have seen code that uses the behavior as a shortcut, whether it is is good practice or not.

$ if "''f'" .eqs. "" then f = "something"

instead of

$ if f$type(f) .eqs. "" then f = "something"

If they do change it, they will have to provide a way to change the value of the checking, for example with a new qualifier to set symbol /noundefined_substitution.

This behavior has been there for at least as long as binary valued symbols have been.

Prior to V3? the following was not valid DCL
$ A = 3

Perhaps Hoff can tell us, although I didn't see anyting explicitly about this behavior in "Writing Real Programs in DCL, Second Edition"

Jon

[Willem Grooters]

I'm not the advocate of change here - being well aware that things do break when behaviour changes, especially when it has been this way for such a long time :). However, an additional mode of operation would be a good thing, similar to SET (NO)VERIFY / F$VERIFY(), perhaps?

[Robert Gezelter]

Willem,

An interesting idea, however, there are some limitations if one needs to preserve the previous "classic" behavior.

A mode setting would be useful, but the question is then how to handle nested command procedures. In some cases, they may be implicit through the use of DCL symbols.

I am not saying that it could not be done, but that care in the definition is needed to preserve the idiosyncratic, but functioning use of the anomaly in the existing code base.

It would be interesting to know if the behavior is a intentional feature, or whether it is an "enshrined" quirk.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert · Accepted solution]

To get equivallent working you can replace
s="Dit is ''bagger'"
by
s="Dit is ''f$str(bagger)'"
Works as before and generates errors when bagger doesn't exist. Can be changed without risk using eve learn.

Wim

[Willem Grooters]

@Bob:
"Similar", not "equal to".
It's just an idea. No more than that. I never said implementation would be easy or without limitations. Some thought:
As you will undoubtably know, one SET VERIFY will effective in called procedures until SET NOVERIFY is encountered. The same couls apply to such a mode switch on symbols. There is another issue, though: the difference between local and global symbols, what to do if SET SYMBOL is encountered?
@Wim:
Good thought, for strings.

BTW: I just tried the arithmatic functions, they all seem to fail if a symbols does not exist:

DKWS38>x=bagger-1
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
\BAGGER\
DKWS38>x=bagger*1
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
\BAGGER\
DKWS38>x=bagger/1
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
\BAGGER\
DKWS38>x=bagger+1
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
\BAGGER\
DKWS38>

that's what I would expect in string handling as well.

[Jon Pinkley]

I would give Wim Van den Wyngaert 10 points for his s="Dit is ''f$str(bagger)'" suggestion.

It will do exactly what you asked for (but does require code changes).

However, I don't agree it is without risks, as the problem can now become that s is undefined, where it would not have been before.

I know of no way using existing DCL to flag it as an informational and to go ahead and treat the undefined sysmbol as if it were a symbol with a null value (the current behavior).

Without going through the code with preceding each line that has symbol substitution within quotes, to do something like

$ if f$type(bagger) .eqs. "" then write sys$output "BAGGER is undefined, being treated as null string"
$ s = "Dit is ''bagger'"

I know of no shortcuts. At least Wim's would be easier to do with a learn sequence.

RE:"BTW: I just tried the arithmatic functions, they all seem to fail if a symbols does not exist: ... that's what I would expect in string handling as well."


$ abc = bagger + "abc"
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
\BAGGER\
$

It is only in quoted substituion that the undefined symbol is trated as if it were a null string.

And I do beleive that is the original way of testing for an undefined symbol before the f$type lexical function existed. But I can't find any reference to back that up.

[Wim Van den Wyngaert]

...for strings...

???

This also works for numerical values. The f$str will convert the symbol to string just as the double quote would do.

Wim