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

[Robert A. Brooks]

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
*
*      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                        */
         )



-- 

                       -- Rob