[Info-vax] Questions about sys$cli()

[Simon Clubley]

On 2019-06-29, Craig A. Berry <craigberry at nospam.mac.com> wrote:
>
> On 6/29/19 5:42 PM, Simon Clubley wrote:
>> * Unless the following 4 descriptor fields are reset to zero, CLI$K_DEFGLOBAL
>>   * fails with a status of 229688 on HPE Alpha V8.4. The reason for this is
>>   * unknown.
>>   */
>> //	sym_name.dsc$b_dtype = 0;
>> //	sym_name.dsc$b_class = 0;
>> 
>> //	sym_value.dsc$b_dtype = 0;
>> //	sym_value.dsc$b_class = 0;
>
> 0 is another name for a type of DSC$K_DTYPE_Z, "unspecified."  Not sure
> if there is a zero class.  What kind of descriptor do the docs for
> sys$cli claim to require?  Oh wait, SYS$CLI is undocumented, so you're
> on your own unless you find a working example, assuming that working
> rather than breaking is what you're interested in.
>

:-)

Sarky devil. :-)

However, yes, the goal is to understand how it works, not how it breaks.

What is interesting is that I needed to clear both dsc$b_dtype _and_
dsc$b_class. Just clearing dsc$b_dtype was not sufficient.

> This example looks plausible (I have not tried to build it but if it's
> the gawk I think it is I have probably run it):
>
><https://fossies.org/linux/gawk/vms/vms_cli.c>
>

This started when I created a test program which used $DESCRIPTOR() to
setup the descriptors and then I promptly found the program didn't work.

I can understand sys$cli() ignoring those fields and just assuming the
type of descriptor being passed to it. What I don't get is why sys$cli()
apparently _requires_ both dsc$b_type and dsc$b_class to be zero instead
of just ignoring them.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world