A boolean bug ?

[mcle...@gmail.com]

Is this a VMS bug?

$!
$! TEST_MISS.COM
$!
$! To test a missing "."
$!
$ A="ABC"
$!
$ IF A .EQS "ABC" THEN GOTO LAB_10
$!
$ WRITE SYS$OUTPUT "NO"
$ EXIT
$!
$ LAB_10:
$ WRITE SYS$OUTPUT "YES"
$!
$ EXIT

(Yeah, it looks a bit odd. It was written to be like some code we have here.)

$ @test_miss
YES

You mean I don't need to put a closing "." on my ".EQS" ?
That's not what the documentation says/implies.

I changed ".EQS" to ".NES" (again no ending ".") and tried that.
The output was NO, as expected.

Have no "." at all (eg. " EQS ") and it's caught as an undefined symbol.

Is it a bug or have I misunderstood something?

[Steven Schweda]

> You mean I don't need to put a closing "." on my ".EQS" ?

Yes.

> That's not what the documentation says/implies.

Which "the documentation", exactly? Implied by the docs,
or inferred by you?

> Have no "." at all (eg. " EQS ") and it's caught as an
> undefined symbol.

Yup. You can abbreviate from the end, not from the
beginning.

> Is it a bug or have I misunderstood something?

More likely the latter. If you find an actual ambiguity
somewhere, then you have legitimate grounds to complain. If
the worst you can say is that these operators can be
appreviated, then you should probably relax and enjoy the
benefits.

[Steven Schweda]

One advantage to the last "." is that it delimits the
operator. Without spaces, for example:

alp $ write sys$output "abc".eqs."ABC"
0

alp $ write sys$output "abc".eqs"ABC"
%DCL-W-IVOPER, unrecognized operator in expression - check spelling and syntax
\.EQS"ABC"\

As usual, many things are possible, and everything is
complicated.

[erga...@gmail.com]

> You mean I don't need to put a closing "." on my ".EQS" ?
> That's not what the documentation says/implies.

There are dozens of corner cases where not-quite-legal DCL silently does something without giving a syntax error. I would class it as undefined behaviour, unless there is some wording in the documentation that I am unware of. However, there isn't much chance of the interpreter changing in a way that would break constructs like that.

[Stephen Hoffman]

On 2015-11-04 22:36:07 +0000, mcle...@gmail.com said:

> Is this a VMS bug?

Probably best to flip the question around. Ask yourself whether this
this code is using documented behavior? Whether you can find
documentation for it.

Rule of thumb: If it's not documented — not documented as working and
supported and not deprecated — then it's not supported.

This DCL code does appear dependent on undocumented, undefined or
subject-to-change behavior.

> Is it a bug or have I misunderstood something?

FWIW, DCL_CHECK objects. Might want to run that tool and find out
what other gremlins lurk here, too.

<http://www.digiater.nl/openvms/freeware/v80/dcl_check/freeware_readme.txt>

But if you want the official answer, lob a bug report at HPE and/or
VSI. A few old undocumented behaviors did become documented and
supported, through the use of this channel.



--
Pure Personal Opinion | HoffmanLabs LLC

[Stephen Hoffman]

Past OpenVMS updates and patches have occasionally blown up sketchy DCL.

As for DCL itself, VSI discussed potential replacements for DCL at Boot
Camp. (Once they dig out of their roadmap and their x86-64 port.)
Bet that at least some sketchy DCL will blow up then, dependent on
whether and exactly how they might decide to overhaul or to replace DCL.

I'd not rush out to fix this now, but I'd add this to the list of stuff
to fix if and as the source code modules are changed, and also possibly
as part of a larger effort to solidify and existing DCL through
something like DCL_CHECK. This depending on how many bugs are in which
parts of the environment — if DCL bugs as a general class of bugs get
near the top of that list in whatever issue-tracking system is in use,
then I'd schedule and start up on this project.

[mcle...@gmail.com]

As a simple example of the documentation,
"$ HELP HINTS Operators_in_expressions" indicates that ".EQS" and
".NES" are correct. (I'm not about to copy the Help output here because it will get reformatted.)

Also in the VMS doc set at
http://h71000.www7.hp.com/doc/731final/6489/6489pro_031.html#string_compare_r

[David Froble]

When using DCL, the commands can be abbreviated to 4 characters. Now, I would
not expect the operators to also allow that, but, perhaps so.

That mentioned, it's my firm belief that command procedures should NOT use
abbreviations. More readable. More specific. The right thing to do. But,
that's just me.

[abrsvc]

I haven't looked at the sources of the parser in a while, but the IIRC operators are handled the same way as commands. This would mean that the first 4 characters (if unique) will be enough.

I do agree however, that in procedures, no abbreviations should be used. With the entire command spelled out, the likelihood of commands being redirected is significantly reduced. For example: using DIRECTORY in a procedure will prevent such things as DIR:==DIR/SIZ from altering the procedure.

Dan

[Norm Raphael]

> On 11/04/15, mcle...@gmail.com wrote:
>
> On Thursday, November 5, 2015 at 9:54:12 AM UTC+11, Steven Schweda wrote:

> > > You mean I don't need to put a closing "." on my ".EQS" ?
> >

> > Yes.

> >
> > > That's not what the documentation says/implies.
> >

> > Which "the documentation", exactly? Implied by the docs,
> > or inferred by you?
> >

> > > Have no "." at all (eg. " EQS ") and it's caught as an
> > > undefined symbol.
> >

> > Yup. You can abbreviate from the end, not from the
> > beginning.
> >

> > > Is it a bug or have I misunderstood something?
> >

> > More likely the latter. If you find an actual ambiguity
> > somewhere, then you have legitimate grounds to complain. If
> > the worst you can say is that these operators can be
> > appreviated, then you should probably relax and enjoy the
> > benefits.
>
> As a simple example of the documentation,
> "$ HELP HINTS Operators_in_expressions" indicates that ".EQS" and
> ".NES" are correct. (I'm not about to copy the Help output here because it will get reformatted.)
>
> Also in the VMS doc set at
> http://h71000.www7.hp.com/doc/731final/6489/6489pro_031.html#string_compare_r
>

That is NOT what I see in either place. The trailing dot is always shown.

I endorse Hoff's suggestion to use DCL_CHECK as a test.

Technically ( ;-) ), simple symbol substitution ['abc] should always be written with a
trailing single-quote ['abc'], but almost nobody does that.

I do not know what VAXMAN's DCLdebugger will show.

Aim for clarity and readability and be very careful of using .EQ. when you mean .EQS.
and vice versa.



Norman F. Raphael
"Everything worthwhile eventually
degenerates into real work." -Murphy

[VAXman-]

Nope!

$ IF 1.NE 2 THEN $WRITE SYS$OUTPUT "NOT EQUAL"


--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

[VAXman-]

In article <52b65ba9-690c-45bf...@googlegroups.com>, abrsvc <dansabr...@yahoo.com> writes:
>I haven't looked at the sources of the parser in a while, but the IIRC oper=
>ators are handled the same way as commands. This would mean that the first=

> 4 characters (if unique) will be enough.

NOT!

See CHARMANIP.LIS and EXPRESS.LIS.

[VAXman-]

My DCL debugger will show what DCL has parsed. If it works in DCL, then it
works in the DCL debugger because it maps DCL.EXE to do all of the parsing.
If that wasn't the case, what use would the debugger have?

[David Froble]

Ok, sheepish admission of guilt. DIRECTORY is one DCL command that I don't
spell out in full. Don't use it much in command procedures. Some use.

[Phillip Helbig (undress to reply)]

In article <386bfa22-ccae-421f...@googlegroups.com>,

mcle...@gmail.com writes:

> Is it a bug or have I misunderstood something?

There are various things which (usually?) work, even though the
documentation says otherwise: Missing " at the end of a line, expanding
a symbol with just a leading quote and no trailing quote, specifying the
owner without square brackets, and so on.

[mcle...@gmail.com]

I stumbled across the absence of a closing(?) "." when I was using DCL_CHECK.

[Norm Raphael]

I'm sorry, but I do not understand what you are trying to say here.
Did DCL_Check report the absence of a closing dot?
Did you stumble across the absence of a closing dot within DCL_CHECK (I doubt that)?
What was the context where a closing dot was missing?
Oh, and how does you reported stumbling help inform this discussion?

[David Froble]

I'm guessing that John was either working on a new command procedure, or,
checking an existing one with DCL_CHECK, and found the operator without the
second ".". Or some variation similar.

Now, when a working command procedure had a discrepancy reported, I'd be curious.

[Paul Sture]

A long time "favourite" of mine:

$ x = "abc"
$ if x .eq. "xyz" then ! should be .eqs.
$ write sys$output "equals xyz"
$ else
$ write sys$output "not equal to xyz"
$ endif

$ @x
equals xyz
%DCL-E-INVIFNEST, invalid IF-THEN-ELSE nesting structure or data inconsistency

It's correct with the "data inconsistency" part, but your eyes are
lead to the IF-THEN-ELSE structure.

--
The major difference between a thing that might go wrong and a thing
that cannot possibly go wrong is that when a thing that cannot possibly
go wrong goes wrong it usually turns out to be impossible to get at or
repair. -- HHGTTG

[Paul Sture]

On 2015-11-05, Norm Raphael <norman....@verizon.net> wrote:
>
>
>> On 11/04/15, mcle...@gmail.com wrote:
> >
>> On Thursday, November 5, 2015 at 9:54:12 AM UTC+11, Steven Schweda wrote:
>> > > You mean I don't need to put a closing "." on my ".EQS" ?
>> >
>> > Yes.
>> >
>> > > That's not what the documentation says/implies.
>> >
>> > Which "the documentation", exactly? Implied by the docs,
>> > or inferred by you?
>> >
>> > > Have no "." at all (eg. " EQS ") and it's caught as an
>> > > undefined symbol.
>> >
>> > Yup. You can abbreviate from the end, not from the
>> > beginning.
>> >
>> > > Is it a bug or have I misunderstood something?
>> >
>> > More likely the latter. If you find an actual ambiguity
>> > somewhere, then you have legitimate grounds to complain. If
>> > the worst you can say is that these operators can be
>> > appreviated, then you should probably relax and enjoy the
>> > benefits.
>>
>> As a simple example of the documentation,
>> "$ HELP HINTS Operators_in_expressions" indicates that ".EQS" and
>> ".NES" are correct. (I'm not about to copy the Help output here because it will get reformatted.)
>>
>> Also in the VMS doc set at
>> http://h71000.www7.hp.com/doc/731final/6489/6489pro_031.html#string_compare_r
>>
>
> That is NOT what I see in either place. The trailing dot is always shown.

I see the same.

(As an aside the corresponding help on VAX/VMS 7.3 displays '--' instead of '-'
for the minus operator)

[Johnny Billquist]

Um... ".NE" would be three characters.
That said, I have no idea about anything else on this topic. :-)

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[VAXman-]

-------------------------------------------------------^^^^^^^^^^^^
-------------------------------------------------------^^^^^^^^^^^^

>>> not expect the operators to also allow that, but, perhaps so.

----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>
>> Nope!
>>
>> $ IF 1.NE 2 THEN $WRITE SYS$OUTPUT "NOT EQUAL"
>
>Um... ".NE" would be three characters.

Right.
QED.

[Johnny Billquist]

Maybe I'm missing something. But if someone throws out a theory of that
operators maybe can be abbreviated to four (4) characters, and you then
prove that they cannot be abbreviated to three (3) characters, what did
you prove?

Put another way - someone throws out a theory that they can be
abbreviated to four characters, and you respond "no", and proceed that
they indeed cannot be abbreviated to three characters. How is that
related to the question/theory?

I must be missing something significant here...?

[mcle...@gmail.com]

Norm,

I ran DCL_CHECK over a command procedure and it reported the missing ".". (I can't recall the error message and I'm not on my VMS system at the moment, so I can't give the exact message.)

I was surprised that the command procedure hadn't failed when it was run, so I did some investigation and found, as per the first message, that a closing "." apparently isn't necessary on .EQS and .NES .

[David Froble]

Whoa, "theory" is way too strong. Note that I doubted the operators would work
that way.

I also have some suspicion that Brian may have had reason to be familiar with
the parser at some time in the past. But he didn't indicate that his statement
was based upon such, so back to speculation.

I'd guess the only real answer lies in the DCL parser, and I for one have no
intention to go there. I'd probably get lost, never to be found. Like "a maze
of twisty passages, all alike" ....

[Stephen Hoffman]

On 2015-11-07 03:16:38 +0000, mcle...@gmail.com said:

> found...that a closing "." apparently isn't necessary on .EQS and .NES .

"Isn't necessary"? That's for VSI to decide.

Isn't currently required by the parser? Empirically, yes. Clearly.

Is undefined, and might break after a patch or an upgrade, or might
blow up during some hypothetical DCL-to-its-replacement translation
tool? Ayup, probably that too.

Undefined behaviors have a long history in some language, including DCL and C:
http://blog.regehr.org/archives/213
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Like C, DCL has had its share of undefined behavior. As I can locate
no documentation indicating that this particular truncation is
permissible, then it's undefined behavior, and entirely up to the DCL
parser de jour whether this truncation works, whether it silently
produces a wrong answer or an error, or whether nasal demons are
involved.

DCL is in many ways a creature of the 1970s, and designs and user
preferences and uses have changed in the ensuing decades. DCL was
intentionally sloppy in what was accepted, and — for reasons of
compatibility — that sloppiness has continued, and has derailed folks.
DCL should have required full commands and full qualifiers from
command procedures, for instance, and not left that as a
recommendation. Then there's just the bizarre, like what happens when
you enter a * as the command. (That'll invoke the first exe or DCL
file found in DCL$PATH. Caveat inputter.)

[Norm Raphael]

On 11/06/15, mcle...@gmail.com wrote:

> <snip>

> Norm,
>
> I ran DCL_CHECK over a command procedure and it reported the missing ".".
> (I can't recall the error message and I'm not on my VMS system at the
> moment, so I can't give the exact message.)
>
> I was surprised that the command procedure hadn't failed when it was run, so I did

> some investigation and found, as per the first message, that a closing "." apparently

> isn't necessary on .EQS and .NES .

Thanks for the explanation. It makes sense.

The truth is that while omitting the closing "." may work, it is not correct syntax, not
as documented, and so it is dangerous not to fix it as DCL_CHECK points out.

[VAXman-]

Yup.

[VAXman-]

I'm pretty sure I refenence the pertinent DCL modules in one post in this
thread.

Abbreviation of characters to 4 works for DCL commands save for those shorter
than 4. That's what I was trying to show with my .NE example. I suppose one
has to be familiar with that DCL verb limitation to understand why what you'd
said does NOT apply to expressions like the .NE.

>I'd guess the only real answer lies in the DCL parser, and I for one have no
>intention to go there. I'd probably get lost, never to be found. Like "a maze
>of twisty passages, all alike" ....

DCL is NOT that difficult to understand. I've spent countless hours in its
code. There are places where it's not well written Macro32 but it's still
easy enough to follow along at home. ;)

[Bob Koehler]

In article <n1l2jv$1rh$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:

> Then there's just the bizarre, like what happens when
> you enter a * as the command. (That'll invoke the first exe or DCL
> file found in DCL$PATH. Caveat inputter.)

Which is why, after some testing, I put $.com in the first directory
in my DCL$PATH. Testing wasn't exhuastive, but it works for me.

$.com issues a simple error message, something about wanting to do
everything, since that's what * implies.

[Bob Koehler]

-- Pyffle HQ -=- London, England -=- http://pyffle.com

[mcle...@gmail.com]

I'm just surprised that after 37 years of VMS we're still learning about some undocumented features(?).

[Stephen Hoffman]

On 2015-11-10 00:29:59 +0000, mcle...@gmail.com said:

> I'm just surprised that after 37 years of VMS we're still learning
> about some undocumented features(?).

From ~ten days ago: <http://labs.hoffmanlabs.com/node/1919>, and
potentially more useful than truncated conditionals...

[Norm Raphael]

> On 11/09/15, mcle...@gmail.com wrote:
>
> I'm just surprised that after 37 years of VMS we're still learning about some undocumented features(?).

>

Well, not to flog a dead equine, but some of us knew about this years ago, but we learned not to use this
kind of rogue construct just because it did not fail, because we did not and still do not trust it, and we
prefer to do the right thing, since there is no advantage in not doing so in this case.

(That is why DCL_CHECK.COM flags it.)

[Hans Vlems]

Hoff, the link you posted (to note 1919) is an example of an undocumented feature.
The missing period in .EQS. is not an undocumented feature. The proper use of the operator and others like it is well documented, deviating from the documentation and still getting desired results is proof of a poor implementation. Similar to using 'P1' and 'P1, both yield the same result.
It ought to be fixed, the DCL parser must adhere to its own specification. Of course that may break existing code, sloppy programming breeds sloppy programs. A DCL parser may be supplied to fix this or flag those errors with -I- level messages, over time upgrading it to level -E- or -F-.
DCL is in part a programming tool and as such must be well defined in both semantics and syntax.
Hans

[Stephen Hoffman]

On 2015-11-11 08:04:56 +0000, Hans Vlems said:

> Hoff, the link you posted (to note 1919) is an example of an
> undocumented feature.
> The missing period in .EQS. is not an undocumented feature. The proper
> use of the operator and others like it is well documented, deviating
> from the documentation and still getting desired results is proof of a
> poor implementation. Similar to using 'P1' and 'P1, both yield the same
> result.
> It ought to be fixed, the DCL parser must adhere to its own
> specification. Of course that may break existing code, sloppy
> programming breeds sloppy programs. A DCL parser may be supplied to fix
> this or flag those errors with -I- level messages, over time upgrading

> it to level -E- or -F-.DCL is in part a programming tool and as such

> must be well defined in both semantics and syntax.Hans

Unless you can find a published BNF or design spec or some specific
documentation of this or of DCL in general, then whether this is an
undocumented feature or a bug is entirely up to the vendor to decide.
Not us.

Would I consider it hazardous to use this truncated conditional? Yes.
Particularly given the lack of documentation. This as I've stated
up-thread, too.

But then I've seen some bizarre DCL behavior become documented and
supported. Evaluating lexical functions in ! comments, for instance.
Somebody at VSI might decide "hey, truncation of conditionals is a cool
new feature we can sell, we should support that. Less typing!"

[VAXman-]

In article <n1vgdb$m5h$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>On 2015-11-11 08:04:56 +0000, Hans Vlems said:
>

>> Hoff, the link you posted (to note 1919) is an example of an
>> undocumented feature.
>> The missing period in .EQS. is not an undocumented feature. The proper
>> use of the operator and others like it is well documented, deviating
>> from the documentation and still getting desired results is proof of a
>> poor implementation. Similar to using 'P1' and 'P1, both yield the same
>> result.
>> It ought to be fixed, the DCL parser must adhere to its own
>> specification. Of course that may break existing code, sloppy
>> programming breeds sloppy programs. A DCL parser may be supplied to fix
>> this or flag those errors with -I- level messages, over time upgrading

>> it to level -E- or -F-.DCL is in part a programming tool and as such
>> must be well defined in both semantics and syntax.Hans
>
>Unless you can find a published BNF or design spec or some specific
>documentation of this or of DCL in general, then whether this is an
>undocumented feature or a bug is entirely up to the vendor to decide.
>Not us.
>
>Would I consider it hazardous to use this truncated conditional? Yes.
>Particularly given the lack of documentation. This as I've stated
>up-thread, too.
>
>But then I've seen some bizarre DCL behavior become documented and
>supported. Evaluating lexical functions in ! comments, for instance.

READREC only allows F$VERIFY to be evaluated. If there are lexicals within
its scope, they'll be evaluated; otherwise, no other lexicals are evaluated
in comments. I'm pretty sure, albeit it's been ages since I've actually had
to read the DCL documentation, this behavior is documented.

[John Reagan]

On Wednesday, November 11, 2015 at 8:41:11 AM UTC-5, Stephen Hoffman wrote:
>
> But then I've seen some bizarre DCL behavior become documented and
> supported. Evaluating lexical functions in ! comments, for instance.
> Somebody at VSI might decide "hey, truncation of conditionals is a cool
> new feature we can sell, we should support that. Less typing!"
>

How can you tell the difference between a "bug" and an "undocumented feature that was incorrectly implemented"? This sounds like a Supreme Court argument about "original intent".

[Hans Vlems]

Language syntax discussions may be more detailed than a Supreme Court decision, if comp.lang.c is an example :-)
The notation for the .eqs. operator and its cousins is documented though. So all other forms are clearly implementation mistakes.
My point was that an undocumented feature is syntactically correct though contains components that are not in the book.

[Stephen Hoffman]

This might involve original intent, but definitely involves current and
future intent. And it is not my call. VSI owns this decision.
Which means we (the not-VSI folks) learn the decision by whether the
bug gets fixed in the code or gets acknowledged EWONTFIX via the
closure of the bug report, or whether the behavior gets documented.
Sometimes a vendor representative publicly indicates "it's a bug" or
"it's a feature". Sometimes the vendor response is ambiguous — no
support contract, not interesting, infinite deferral, whatever — and
the determination of status escapes on a technicality.

This being OpenVMS — where upward-compatibility is valued, and where
some internal DCL changes can potentially be perceived as being low
value and/or high risk — sometimes the developer — we'll use the name
Herr Schrödinger as the current maintainer of DCL — doesn't really even
want to open the box for a look.

Until and unless there's a status determination, I don't see this
truncated-conditional DCL (mis?)behavior as being particularly
dependable.

Though none of us like having to migrate our code, VSI might eventually
decide that it is even necessary to deprecate and remove certain
documented interfaces, too.

[John Reagan]

On Wednesday, November 11, 2015 at 3:11:00 PM UTC-5, Hans Vlems wrote:
> Language syntax discussions may be more detailed than a Supreme Court decision, if comp.lang.c is an example :-)

Even I have limits...

I recall one Pascal standards meeting many years ago. One of the members brought a game called "Semantics" to play in the bar in the evenings. We spent the whole night arguing about ambiguities in the instructions/rules. That was probably more fun then the game itself.

[Hans Vlems]

I do hope you appreciate me holding back in this discussion to avoid ending up in exactly such an argument :-) !!