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

On 2021-12-01 21:23:41 +0000, hb said:

> On 12/1/21 8:50 PM, Stephen Hoffman wrote:
>> 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.
>
> The linker matches symbols, which represent references and definitions.
> It complains if it can't find a matching definition for a reference.
> The symbol name and the symbol type must match. That is the linker
> knows about data and routines. It will not let you define an object for
> a routine reference. That's more or less all the linker does, here.
>
> With C++ you get the API encoded in the symbol name, also known as
> "decorated" or "mangled" name. With matching such symbols the linker
> implicitly checks the API and does notice a difference, that is, it
> will print an unresolved reference warning. For example, if you call
> (or take the address of) "foo(int,int)" but only define a "foo(int)"
> you will see
>
> %ILINK-I-UDFSYM, CX3$_Z3FOOII2INROLH
> %ILINK-W-USEUNDEF, undefined symbol CX3$_Z3FOOII2INROLH referenced
> source code name: "foo(int, int)"

I'm aware of how the OpenVMS linker works here, as well as with the
OpenVMS implementation of mangling, hence my comment quoted above.

Past resolving the associated symbol—symbol resolution which would
necessarily happen with or without name mangling in use—the C and C++
name mangling doesn't involve the OpenVMS linker.

Nor does the OpenVMS linker check the APIs.

Mangling is in some ways used as a workaround for linker limits around
symbol resolution (as is used on OpenVMS), and also used as a
workaround for linker features lacking (across various languages and
compilers and linkers, including as used on OpenVMS).

Mangling is a hack, but it's the hack we have.

--
Pure Personal Opinion | HoffmanLabs LLC

On 12/2/2021 11:36 AM, John Reagan wrote:
> On Wednesday, December 1, 2021 at 9:31:29 PM UTC-5, Tim Sneddon wrote:
>> Dave Froble <da...@tsoft-inc.com> wrote:
>>> 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

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

> You can suppress that run-time check (and other heavy-handed BASIC features) with
>
> OPTION INACTIVE=SETUP
>
> In the routine.

But Basic is correct - there are too many arguments
supplied (or too few arguments expected).

It much be better to fix that than to disable the check.

Arne

On 12/2/2021 3:14 PM, Arne Vajhøj wrote:
> On 12/2/2021 11:36 AM, John Reagan wrote:
>> On Wednesday, December 1, 2021 at 9:31:29 PM UTC-5, Tim Sneddon wrote:
>>> Dave Froble <da...@tsoft-inc.com> wrote:
>>>> 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
>
>>> $ 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.
>
>> You can suppress that run-time check (and other heavy-handed BASIC features) with
>>
>> OPTION INACTIVE=SETUP
>>
>> In the routine.
>
> But Basic is correct - there are too many arguments
> supplied (or too few arguments expected).
>
> It much be better to fix that than to disable the check.
>
> Arne

You going to advocate "fixing" that "lack of argument count check" in C and
other languages too?

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

On 12/2/2021 11:36 AM, John Reagan wrote:

> You can suppress that run-time check (and other heavy-handed BASIC features) with
>
> OPTION INACTIVE=SETUP

Awesome John. But I have to ask, is there any documentation of all the compiler
options such as that? Maybe I should just RTFM ? Nah, what's the fun in that?

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

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

On 12/2/2021 3:43 PM, Dave Froble wrote:
> On 12/2/2021 3:14 PM, Arne Vajhøj wrote:
>> On 12/2/2021 11:36 AM, John Reagan wrote:
>>> You can suppress that run-time check (and other heavy-handed BASIC
>>> features) with
>>>
>>> OPTION INACTIVE=SETUP
>>>
>>> In the routine.
>>
>> But Basic is correct - there are too many arguments
>> supplied (or too few arguments expected).
>>
>> It much be better to fix that than to disable the check.
>
> You going to advocate "fixing" that "lack of argument count check" in C
> and other languages too?

I would not advocate changing C, but I would advocate not using
C unless one really needs the low level features.

C is a great language for code that 40 years ago would have been
written in Macro-32. It is a poor language for code that 40 years
ago would have been written in Pascal, Ada or Basic.

Unfortunately the dominance of C API's for native code are often
forcing the usage of C.

Arne

On 12/2/2021 3:45 PM, Dave Froble wrote:
> On 12/2/2021 11:36 AM, John Reagan wrote:
>> You can suppress that run-time check (and other heavy-handed BASIC
>> features) with
>>
>> OPTION INACTIVE=SETUP
>
> Awesome John.  But I have to ask, is there any documentation of all the
> compiler options such as that?  Maybe I should just RTFM ?  Nah, what's
> the fun in that?

The FM called "Basic Reference Manual" lists:

INTEGER OVERFLOW
DECIMAL OVERFLOW
SETUP
DECIMAL ROUNDING
SUBSCRIPT CHECKING

Arne

On 12/2/21 3:43 PM, Dave Froble wrote:
> On 12/2/2021 3:14 PM, Arne Vajhøj wrote:
>> On 12/2/2021 11:36 AM, John Reagan wrote:
>>> On Wednesday, December 1, 2021 at 9:31:29 PM UTC-5, Tim Sneddon wrote:
>>>> Dave Froble <da...@tsoft-inc.com> wrote:
>>>>> 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
>>
>>>> $ 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.
>>
>>> You can suppress that run-time check (and other heavy-handed BASIC
>>> features) with
>>>
>>> OPTION INACTIVE=SETUP
>>>
>>> In the routine.
>>
>> But Basic is correct - there are too many arguments
>> supplied (or too few arguments expected).
>>
>> It much be better to fix that than to disable the check.
>>
>> Arne
>
> You going to advocate "fixing" that "lack of argument count check" in C
> and other languages too?
>

They did fix it in C. They called it C++. :-)

bill

On Thursday, December 2, 2021 at 3:45:49 PM UTC-5, Dave Froble wrote:
> On 12/2/2021 11:36 AM, John Reagan wrote:
> > You can suppress that run-time check (and other heavy-handed BASIC features) with
> >
> > OPTION INACTIVE=SETUP
> Awesome John. But I have to ask, is there any documentation of all the compiler
> options such as that? Maybe I should just RTFM ? Nah, what's the fun in that?
> > 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.
> >
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486
Yep, RTFM.

https://docs.vmssoftware.com/vsi-basic-for-openvms-reference-manual/#d0e26113

On Wednesday, December 1, 2021 at 3:46:00 PM UTC-5, Arne Vajhøj wrote:
> On 12/1/2021 3:35 PM, Dave Froble wrote:
> > 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.
> >
> > :-)
> Basic is different from some more low level languages.
>
> But I don't see a problem with Basic here.
>
> The AST function is being called with 5 arguments and
> the AST function is declared to receive 1 argument, so
> something in the generated code does not like it.
>
> Seems perfectly fair to me.
>
> Obviously the documentation should be very clear
> about the 5 arguments.
>
> Arne
Arne,

I know this problem. Encountered it at a client.

BASIC checks the parameter count. Done. C and others do not .

- Bob Gezelter, http://www.rlgsc.com

On 12/2/21 9:04 PM, Stephen Hoffman wrote:
> Mangling is in some ways used as a workaround for linker limits around
> symbol resolution (as is used on OpenVMS), ...

If you refer to the length of the symbol name, there is no limit in the
current VMS linker other than the amount of memory available to the
linker when linking the image. If you refer to another limit or to the
VAX and Alpha linker, let us know.

On Friday, December 3, 2021 at 5:06:27 AM UTC-5, hb wrote:
> On 12/2/21 9:04 PM, Stephen Hoffman wrote:
> > Mangling is in some ways used as a workaround for linker limits around
> > symbol resolution (as is used on OpenVMS), ...
>
> If you refer to the length of the symbol name, there is no limit in the
> current VMS linker other than the amount of memory available to the
> linker when linking the image. If you refer to another limit or to the
> VAX and Alpha linker, let us know.
On the other hand, the librarian does have some length limits but the max/default is 1024.

Almost all of the imposed limits are in the compiler dating back to the days of the VAX linker and the Alpha linker.

No DEC language is EASY to migrate.
in 1M lines of VMS COBOL there will be (generally) 120,000 individual instances that need to be remediated either manually or automatically.
just count how many BY DESCRIPTORS there are your code and that doesn't even scratch the surface.
for PASCAL we had to wrote a DEC PASCAL to C++ converter - does a great job - no other option.
for BASIC we wrote a VAX BASIC to C translator.
for FORTRAN we have FORTRAN partner which is a mil spec VMS FORTRAN to ifort translator - yes - fort is very DEC compatible but dropped many of theold VMS "things" - like initialized common blocks - can have multipack on VMS - only 1 on linux.
Even DEC C in large quanties can be a real pain the the ass - &0, &sizeof, fopen extended to use rms extensions.
we have a DEC COBOL to Fujitsu COBOL / MF COBOL translator - and it earns every penny
Generally - you can assume that every large DEC 3GL application (1M to 2M LOC) will have 100K+ code modifications to even compile on an ANSI 3GL.
C++ is obviously the easiest - but not immune to DEC isms (you can printf a "string" class)
DEC C - depending on age - can quickly become a quagmire - and we wrote a DEC C to ANSI C converter.

/Jon

On Thursday, November 25, 2021 at 4:07:17 PM UTC-6, Arne Vajhøj wrote:
> On 11/25/2021 4:04 PM, Bill Gunshannon wrote:
> > On 11/25/21 2:20 PM, Arne Vajhøj wrote:
> >> Those running VMS today are mostly those without an easy way off
> >> VMS.
> >
> > I would really like to know what people could be running on
> > VMS on an Itanic that would be so difficult to move to a
> > totally different system. Any applications are almost
> > guaranteed to be written in an HLL. Just what is it that
> > they are doing on VMS that can not be done on another
> > system?
> It can be done on another OS.
>
> But the cost and risk migrating can be significant.
>
> VMS specific language extensions, SYS$ and LIB$ calls,
> reliance on special features in Rdb or index-sequential
> files not available in other RDBMS or ISAM, huge amount
> of DCL scripts, Macro-32 pieces etc.etc..
>
> A thousand easily solvable problems can when combined
> be a very problematic cost and risk (risk may very
> well be considered a bigger problem than cost).
>
> It obviously depend on how the code is written. Some
> C or Cobol programs may be pretty easy to migrate.
> Most Pascal and Basic programs would be a rewrite from
> scratch to migrate.
>
> Arne