[Info-vax] completion status from LIB$SPAWN

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> 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.
> 

If more reasons are needed, a constant name is usually more descriptive than some numeric 
value.  STS$M_SUCCESS is even more descriptive than SS$_NORMAL, but I've been in the habit 
of using the "SS" constants for a long time, and you know about old dogs and new tricks.

Just about anything is more descriptive than "1".