[Info-vax] VMS internals design, was: Re: BASIC and AST routines

[Tim Sneddon]

Dave Froble <davef at tsoft-inc.com> wrote:
> On 12/1/2021 2:50 PM, Stephen Hoffman wrote:
>> On 2021-12-01 19:41:00 +0000, Dave Froble said:
>>
>>> On 12/1/2021 10:52 AM, Stephen Hoffman wrote:
>>>> On 2021-12-01 02:11:19 +0000, Phil Howell said:
>>>>
>>>>> You are not  alone in your confusion
>>>>> See this post from a long time ago
>>>>> https://community.hpe.com/t5/Operating-System-OpenVMS/AST-routine-and-C-language-va-count-va-start-va-end-etc/td-p/4878940#.YabUqew8arU
>>>>>
>>>>>
>>>>
>>>> I'd forgotten about that thread.
>>>>
>>>> What a wonderfully inconsistent trashfire ASTs are.
>>>>
>>>> Somebody at VSI probably now has some (more) writing to do, and some (more)
>>>> of the existing documentation to review.
>>>>
>>>> And it seems some BASIC declaration somewhere for the AST API is arguably
>>>> busted.
>>>>
>>>> Ah, well.
>>>>
>>>>
>>>
>>> I'm a bit afraid to ask another question.  The last question I asked seemed to
>>> start weeks of, not sure what to call it, but some of it was rather nasty.
>>>
>>> Oh, well, another question.
>>>
>>> I haven't done any research, so the question might have a simple answer.
>>>
>>> When as AST is specified while calling a system service, and an AST parameter
>>> can be specified, other than following the docs, what causes me to need to
>>> specify 5 parameters in the AST subroutine?  Unless I declare the subroutine
>>> with 5 parameters, I don't know what might enforce such a requirement.
>>>
>>> Ok, I really should just go and try it myself, but, I'm lazy.  Anyone have a
>>> simple answer?
>>
>> I usually declare the subroutine with one argument for an AST routine, and
>> that's the context pointer. That's worked in C and C++ for an aeon or three.
>>
>> Though whether it breaks with x86-64 port?
>>
>> And I usually use a pointer to some app-local data structure, as that's where I
>> stash the IOSB or whatever other connection-specific details are required for
>> the AST.
>>
>> It's also where I stash the "unwind in progress" flag, if I'm cancelling some
>> operation and it's unclear whether the cancel or the AST will arrive first.
>>
>> If that one-argument declaration is tolerated by BASIC, use it.
>>
>> The Linker isn't particularly sensitive to API declarations, and will probably
>> not notice any API differences. API contract "enforcement" here is usually by
>> app failure.
>>
>> Otherwise???if BASIC won't play nice with a one-argument AST declaration???specify
>> the context pointer and whatever other four values will be tolerated by BASIC
>> and the Linker.
>>
>>
>>
> 
> Ok, got a bit un-lazy, tried it.
> 
> This works:
> 
> 1       !************************************************
>         !     Timer AST Timeout Handler to Cancel I/O
>         !************************************************
> 
>         SUB TCP_TIMER(  LONG CH% , &
>                         LONG Z2% , &
>                         LONG Z3% , &
>                         LONG Z4% , &
>                         LONG Z5% )
> 
>         CALL SYS$CANCEL( Loc(CH%) By Value )
> 
>         SubEnd
> 
> This does not work:
> 
> 1       !************************************************
>         !     Timer AST Timeout Handler to Cancel I/O
>         !************************************************
> 
>         SUB TCP_TIMER(  LONG CH% )
> 
>         CALL SYS$CANCEL( Loc(CH%) By Value )
> 
>         SubEnd
> 
> It seems to have a problem when issuing a read on an I/O channel, not when 
> invoking the QIO that specifies the AST routine.
> 
> I'm not complaining, this was just a test.  I'm a bit curious what caused the 
> error, there was no evident error code or such.
> 
> In the debugger, there was a report of "too many arguments" or something like 
> that.  I'm just guessing that at some point Basic caused some count of arguments 
> and decided that there were too many arguments for the routine as declared.

And there is your answer...

$ HELP/LIBRARY=BASICHELP RUN_TIME_ERRORS TOOMANARG

RUN_TIME_ERRORS

  TOOMANARG


     Too many arguments (ERR=89)

     A function call or a SUB or FUNCTION statement passed  more  arguments
     than  were  expected.   Reduce  the  number  of  arguments.   A SUB or
     FUNCTION statement can pass a maximum of approximately  32  arguments:
     a  function  call  can  pass a maximum of eight arguments.  This error
     cannot be trapped with a BASIC error handler.

There is also an accompanying TOOFEWARG.  BASIC does a lot of things to
protect your fingers from the saw.  Howeever, this is not like a blade
guard, more like a pack up the saw in the box and send it back!

Just another reason why BASIC is not one of my favourite languages...

Regards, Tim.