[Info-vax] completion status from LIB$SPAWN

[VAXman- at SendSpamHere.ORG]

In article <1ots69-i79.ln1 at news.sture.ch>, Paul Sture <paul at sture.ch> writes:
>On Fri, 27 Apr 2012 18:54:32 -0400, David Froble wrote:
>
>> Many years ago the argument for the constants and masks was, "DEC could
>> change the value of something, and using the constants would mean your
>> code would still work".  I've never seen any thing like this change, and
>> I doubt I ever will, and if it happens it would be in my opinion a huge
>> mistake.  Regardless, DEC encouraged the use of the constants...
>
>IIRC somewhere around the transition from V3 to V4, error message numbers 
>could and did change.  You were safe if you had used the constant names 
>in programs, but existing DCL procedures with hard coded error numbers 
>could break.
>
>I definitely recall that during our migration to V4.0, I wrote some DCL 
>which did something like this:
>
>$ create xyzzy.dat
>foo
>$ sea xyzzy.dat cobblers
>$ search_nomatches_status == $status
>$ write sys$output search_nomatches_status
>
>because I didn't trust the hard coded value that was in an existing 
>procedure to remain the same in future releases.
>
>Just to prove that point, running the above on V8.3:
>
>%SEARCH-I-NOMATCHES, no strings matched
>%X08D78053
>
>and on V3.0
>
>%SEARCH-I-NOMATCHES, no strings matched
>%X08018053

It's ALWAYS good coding to reference the symbolic name of a constant whether
it be defined in some include library or at link time from a .STB file.  The
include library constants are much more stable in their definitions than the
contants in an .STB but it's still bad programming practice to hardcode some
value based upon empirical observation.

"if (sts == RMS$_FNF)" has much more meaning than "if (sts == 0x18292)" or
worse "if (sts == 98962)".  I really hate shit like that in decimal.  I've
one customer coding in COBOL and there's no hexadecimal so they've littered
their code with meaningless decimal constants and then ask me for help when
something doesn't work.  

'Tis a shame that there aren't any symbolics for DCL.  That's was one of the
reasons why I added the /EXECUTIVE qualifier to my SYMBOL utility and with a
combination of PIPE, LIBRARY/EXTRACT and SYMBOL one can set symbolic constant
values from the .MLB libraries as DCL symbols.  It's just iffy to expect that
the value of ABC$_XYZZY established in DCL (or any program) will always what
value was observed at the time of its writing.

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

Well I speak to machines with the voice of humanity.