Definition of parameters for $CRMPSC_GDZRO_64 in BASIC$STARLET.TLB

[dankskw]

Hi folks,

I'm trying to use $CRMPSC_GDZRO_64 on OpenVMS V8.3 using Alpha BASIC 1.7-000.

BASIC$STARLET.TLB creation date is 29-Jun-2006.

The definition of the call parameters are reflected correctly in BASIC$STARLET.tlb documentation:

    !      $CRMPSC_GDZRO_64  gsdnam_64, ident_64, prot, length_64, region_id_64, section_offset_64,
    !                    acmode, flags, return_va_64, return_length_64
    !                    [, start_va_64[, map_length_64[, reserved_length_64[, rad_mask[, page_prot]]]]]
    !
    !   gsdnam_64       = Address of global section name string descriptor
    !                     (32-bit or 64-bit descriptor)
    !
    !       ident_64    = Address of quadword containing version id and match control
 ...

However, the actual definition of the arguments in the function are incorrect:

      EXTERNAL LONG FUNCTION  SYS$CRMPSC_GDZRO_64 &
               ( &
                   LONG  BY VALUE, &
                   BASIC$QUADWORD  BY REF, &
...

The repair is apparent, but we are reluctant to make changes that will be overridden by software updates.

Most, perhaps all of the descriptor references are incorrect in the same way.

Has this been addressed in a more recent release of Alpha BASIC more current than the one we have (1.7-000)

Please does someone in this forum know how we could get this fixed if it hasn't already been?

Thank you for any help.

[John Gillings]

Include files and definition libraries belong to the operating system, not to the language. They should only be updated by an Operating System upgrade.

System supplied definitions should be considered "advisory" or "example" code. If you don't like the content or style, feel free to provide your own.

For most languages, the definitions are generated automatically from SDL. Some of the time, definitions which can't be precisely defined in a particular language will be filled with a generic definition like LONG BY VALUE. Most language have a means for overriding type and mechanism formal definitions with actual definitions. In BASIC you would use "BY VALUE", "BY REF" or "BY DESC". You may be able to work around the issue in your code by writing something like:

stat =  $CRMPSC_GDZRO_64 (BY DESC $GSDNAM

 This should continue to do what you intend regardless of changes to the starlet library.

In your case it's a bit strange to see something as simple as a string descriptor filled in as LONG BY VALUE, but I see that the Pascal definition for the same argument is similarly defined:

TYPE
        $DEFTYP = [UNSAFE] INTEGER;
        $DEFPTR = [UNSAFE] ^$DEFTYP;

[ASYNCHRONOUS,EXTERNAL(SYS$CRMPSC_GDZRO_64)] FUNCTION $CRMPSC_GDZRO_64 (
        %IMMED GSDNAM_64 : $DEFPTR;

 that suggests it's deliberate. Perhaps  because this allows both 32 and 64 bit descriptors? Some other places in STARLET where a parameter is described as "(32-bit or 64-bit descriptor)" are defined the same, but then some are "STRING BY DESC". Pascal definitions mirror the Basic ones.

Probably worth logging a case with HP Customer Support to get an official answer, but don't hold your breath waiting for it to be changed.

[Hoff]

I would not expect this area to see any particular changes and I would expect this error to show up only during source code builds, so I would have no qualms around modifying the system definitions here.  

As part of these changes, I would document (comment) the source code around these calls with the details of the errors issued and the compiler diagnostics and information on the include-file fix that was implemented on the off-chance it gets undone by some subsequent upgrade.  As a form of collective memory of this fix.

This is arguably a bug the argument declarations within the  SDL source file for the STARLET definitions for this system service; in the file that's used to generate the include files for the various languages.  (Though I don't know of a specific SDL syntax declaration of a 64-bit string descriptor, and that might well be the trigger here.)

If you want the official answer, ring up HP support.