[Info-vax] F$GETQUI: the mystery deepens

[Stephen Hoffman]

On 2018-12-08 18:26:08 +0000, Phillip Helbig (undress to reply said:

> In article <puep8r$tke$1 at dont-email.me>, Stephen Hoffman
> <seaohveh at hoffmanlabs.invalid> writes:
> 
>> This is some long-standing, documented and entirely expected DCL stupidity.
>> 
>> Quoth the f$getqui docs:
>> 
>> "Restriction
>> 
>> The GQC that is saved for wildcarded F$GETQUI calls is destroyed if you 
>> run any DCL queue-related command, such as SHOW QUEUE or SHOW ENTRY. To 
>> avoid this problem, use the SPAWN command to create a new process in 
>> which to run the DCL commands."
> 
> It's not completely destroyed...

Just as soon as this is considered undefined, any potential behavior 
becomes entirely possible.  Entirely random, 
seemingly-predictable-but-not, phase of the moon dependent, we hate 
Monday, or otherwise.  Anything goes, here.

Undocumented behavior is undocumented behavior.

Dependencies on undocumented behavior are perilous at best, and can 
silently produce bad data.

As for researching the behavior?  I know of a few select cases where 
the developers learned of that research, and very deliberately took 
steps to break those assumptions in subsequent releases.  There's some 
value in doing that too, as it preserves flexibility for future 
changes.  I'd much rather have those dependencies detected and trapped 
hard rather than silently fail, too.  But that's not always possible.

See "Nasal Demons" and related discussions for what's possible within 
undocumented or undefined behavior:
https://en.wikipedia.org/wiki/Undefined_behavior

Look up "Hyrum's Law" for some of the fallout that arises when folks 
seemingly inevitably accrue dependencies on undocumented behaviors, too:
http://www.hyrumslaw.com

If you're into some more recent discussions:
https://blog.regehr.org/archives/1520

And for C and C++ developers...
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

OpenVMS has been far too fond of documenting itself out of these sorts 
of cases—of not fixing or not locking out the behavior, and for any of 
various reasons—but that's fodder for several more discussions.



-- 
Pure Personal Opinion | HoffmanLabs LLC