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

[Dave Froble]

On 12/1/2021 9:31 PM, Tim Sneddon wrote:
> 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.
>

Thanks Tim, that really does clear things up.  I got no problem following the 
directions, (when all else fails read the directions), I just was curious about why.

I'm told that some compilers are more rigid than some others, with insuring the 
argument count when setting up the call to a subroutine or function.

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