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

[Dave Froble]

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.

I hate it when the computer thinks it's smarter than me.  Of course that bar 
isn't too high.

:-)

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486