[Info-vax] completion status from LIB$SPAWN

[Paul Sture]

On Sat, 28 Apr 2012 12:33:54 +0000, VAXman- 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.

Worse still, back when we were using an extensive library of APIs, common 
errors such as "record not found" were assigned library-specific error 
codes.  Easy enough until you got an RMS error that wasn't mapped to one 
of those codes, and then you got the RMS code instead.  However these 
were all integer:2 parameters, so you just got the word value instead of 
the longword value returned (cue a bit of DCL to do the conversion, but, 
ah well...).

> 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.

<cough>

Ripped from a bit of COBOL I have lying around:

01 status_value   pic 9(9) comp.

01 ss$_normal     pic 9(9) comp    value external ss$_normal.
01 ss$_abort      pic 9(9) comp    value external ss$_abort.

01 lib$_nosuchsym pic 9(9) comp    value external lib$_nosuchsym.

01 rms$_fnf        pic 9(9) comp    value external rms$_fnf.
01 rms$_rnf        pic 9(9) comp    value external rms$_rnf.

where pic 9(9) comp represents a longword

In early versions of COBOL on VMS, underscores (and probably dollar
signs) weren't allowed, but something like RMS-FNF was a reasonable 
substitute.  And looking at the above code (from 1998) I would nowadays 
use uppercase for those names for readability, not that it makes any 
difference in COBOL, which has case insensitive variable names.

> '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.

At some point before I discovered the ability of COBOL to bring in VMS 
status codes as externals, I did write a bit of DCL to extract values 
from the .MLB libraries and generate the appropriate COBOL definitions.

What I really wanted to do on top of that was a similar exercise for the 
various system services itemlist definitions (which come with all the  
DEC compilers except for COBOL), but I never got around to it.

-- 
Paul Sture