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

[John Reagan]

On Wednesday, December 1, 2021 at 9:31:29 PM UTC-5, Tim Sneddon wrote:
> Dave Froble <da... 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.

You can suppress that run-time check (and other heavy-handed BASIC features) with

OPTION INACTIVE=SETUP

In the routine.  (Don't yell at me about that ugly syntax.  It makes my skin crawl too.)
I saw a reference to a /SETUP and /NOSETUP qualifier while reading the comments, but I don't see that qualifier in the compiler at all.