Article 170636 of comp.os.vms: In article <33856293.2781@desy.de>, "Maria Carmela Petrucci (Rome)" writes: : I have a Fortran code which uses global sections to : make sharable some variables to different tasks. : This global section is in one common block. Older Fortran tends to use COMMON blocks. Languages that support pointers, such as the newer Fortran standards and C, are *far* better off using the run-time global section construct, and the sys$crmpsc system service calls, to map the shared memory dynamically. (Be aware that one can _not_ store addresses in a shared memory area, unless that shared area is marked position dependent. One can store a base-relative offset, as this offset value can be referenced and/or dereferenced, according to the virtual address space of each process, into a virtual address. #define P0SPACE ((void*)0x0200) void *InAdr1[2] = {P0SPACE,P0SPACE}; void *RetAdr1[2] = {NULL,NULL}; void *InAdr2[2] = {P0SPACE,P0SPACE}; void *RetAdr2[2] = {NULL,NULL}; $DESCRIPTOR( SecDsc, "FACNAM_GLOBAL_SECTION_NAME" ); /* \\ open the backing file here, if necessary, using // sys$open with the UFO option, passing the channel \\ number into sys$crmpsc via the fab->fab$l_stv cell // from the open -- if no backing file is needed, then \\ one can omit this whole (sub)project... */ RetStat = sys$crmpsc( InAdr, RetAdr, PSL$C_USER, SEC$M_EXPREG | SEC$M_WRT | SEC$M_DZRO | SEC$M_GBL, &SecDsc, 0, 0, fab->fab$l_stv, 1, 0, 0, 0 ); if (!$VMS_STATUS_SUCCESS( RetStat )) lib$signal( RetStat ); Once the above is executed, RetAdr[0] contains the base address of the global section, and this value can then be assigned to a pointer to a structure, etc. Be aware that using global section system services to map to an installed common is *not* supported, and this technique *will* break at V6.2, as OpenVMS changed the installed image image section naming conventions -- this change allows multiple images to be installed under the same image name, something that was not permitted prior to V6.2. (Applications that map directly via sys$crmpsc calls will fail, though applications that use the LINKER will continue to operate with COMMONs as expected, assuming no other component shareable images changed in size sufficiently to cause address space collsions with the COMMON image(s).) If you cannot reimplement the design while translating... :PSECT_ATTR=EXTDATA,PAGE :COLLECT=SHARED_CLUS,EXTDATA : : where EXTDATA is the name of the common block. : : Now I would like to translate the same code in C. The above syntax is (obviously) from the LINKER, and the syntax is (obviously) the same for an application written in Fortran as it is for one written in C. Where things differ is in the host syntax -- how one declares and locates the address of the COMMON memory in the C application code... In this case, one uses the DEC C -- I'm assuming DEC C, since that compiler is licensed via a current "C" PAK and can coexist with the much older VAX C compiler -- #pragma extern_model pre-processor command (or the associated CC command qualifier of the same name) to select the common_block option. You will likely want to bracket the common block external symbol(s) with a #pragma extern_model save followed by #pragma extern_model restore, to maintain the default memory mapping model for any other external declarations... But I would recommend using a global section and position-independent coding, and would tend to avoid using position-dependent, LINK-time static, COMMON. -------------------------- pure personal opinion --------------------------- Hoff (Stephen) Hoffman OpenVMS Engineering h*ffman@xdelta.enet.dec.c*m headers and addresses munged to avoid automated spammers: junk-e-mail