[Info-vax] GKS : gopwk problem with VSI's version of GKS

[Craig A. Berry]

On 3/17/21 10:30 AM, Robert A. Brooks wrote:
> On 3/17/2021 10:49 AM, Stephen Hoffman wrote:
>> On 2021-03-17 11:59:22 +0000, Paul Hardy said:
>>
>>> Joukj <joukj at hrem.nano.tudelft.nl> wrote:
>>>> Hi all,
>>>>
>>>> I try to call GKS from a Fortran program. All worked fine with de 
>>>> "HP GKS". However when upgrading to "VSI GKS" I got problems 
>>>> initializing GKS. It looks like the call to GOPWK should be adapted:
>>>>
>>>> What always worked was:
>>>> CALL GOPWK(1, 0 , GWSDEF )
>>>> It looks like the second parameter is not integer anymore in VSI-GKS 
>>>> but a character string (I get the error "Invalid representation of 
>>>> integer in translated string")
>>>>
>>>> I have no idea what to fill  in for the second parameter to get the 
>>>> default connection ID. The examples the installation stored on disk 
>>>> only  show an integer parameter here.Who can get me a hint on how to 
>>>> call GOPWK in a proper way.
>>>>
>>>> I tried this on OpenVMS8.4-2L1 with VSI-GKS 7.3 (and HP-GKS V7.2 for 
>>>> reference) and VSI Fortran V8.3-104957-50Q83 running on IA64.
>>>> regards Jouk
>>>>
>>>
>>> In terms of the GKS standard, the second parameter must be an integer 
>>> passed into GOPWK and is CONID the connection identifier - described 
>>> as the channel that the operating system will use to communicate with 
>>> the workstation - probably originally the Fortran unit number.
>>>
>>> If VSI is expecting a string, then it’s a bug/ violation of standard.
>>
>> Well, no.
>>
>> The argument in question here is of variable type, with that type 
>> dependent on the values of another.
>>
>> Related info:
>> http://ngwww.ucar.edu/fund/chp6-10/workstations.html
>> https://linux.die.net/man/3/ncl_gopwk
>> http://vtda.org/docs/computing/DEC/VMS/AA-MJ29A-TE_DEC_GKS_FORTRAN_Binding_Reference_Manual_Apr1989.pdf 
>>
>> http://vtda.org/docs/computing/DEC/VMS/AA-HW44C-TE_DEC_GKS_Reference_Manual_Volume_II_Apr1989.pdf 
>> (appendix A; there's something to be said for a manual that's ~half 
>> appendix, too. Also see that CONID_DEFAULT is also language-specific, 
>> on page A-3)
>>
>> I find vanishingly few references to GWSDEF, so I might wonder if 
>> that's a now-archaic DEC extension.  And I'd wonder whether GWSDEF 
>> might default differently in this GKS.
>>
>> One of the few references to GWSDEF is on page 230 here: 
>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.907.5093&rep=rep1&type=pdf 
>>
> 
> The below is from the engineer who did the work to build GKS for VSI 
> (not me).
> 
> "The code I ported to VSI IA64 is the code I got from HP so nothing 
> should have changed.
> It looks like the second parameter is a pointer to an integer. The 
> following is from FB_CONTROL.C"
> 
> /*+
> * GOPWK  Open workstation (GKS3D_OPEN_WS)
> *
> * Description:
> *      A workstation of given i.d. and type is opened, where the
> *      'conid' arguement is
> *
> *      either: a null pointer or a pointer to the value FB_DEF_LUN,
> *              in which case the kernel is passed a null conid
> *              string descriptor, which results in the kernel
> *              trying to translate the appropriate logicals -
> *              this is how an application can use defaults that
> *              can be changed by changing a logical or enviromental
> *              variable

My Fortran is awfully rusty, but if the intent is to pass a NULL
pointer, wouldn't the second argument need to be %VAL(0) rather than 0?
As it is you're supplying a pointer to a constant whose value is zero
rather than a NULL pointer.  Or try supplying FB_DEF_LUN, assuming some
header you have access to defines that.

> *
> *      or:     a pointer to a non-zero integer, which is interpreted
> *              as a logical unit number; in this case we inquire
> *              to find out (a) if the lun is open (b) does the attached
> *              file have a name - if open, then it is closed so that the
> *              kernel  can re-open it, since the kernel always assumes
> *              closed workstations - if there is no name then one is
> *              constructed according to the assumptions of the compiler
> *              in use;  whatever name we end up with is passed to
> *              the kernel.
> …
> gopwk(
>          int         * wsid,         /*  workstation 
> identifier                  */
>          int         * conid,        /*  connection 
> identifier                   */
>          int         * wstype        /*  workstation 
> type                        */
>          )
> 
> 
>