CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") (05/31/88)
In response to an appropiate rebuke for proposing a solution that required privledges to peform the sharing of data between the same process using INSTALLed images, I offer ANOTHER alternative. There IS a feature of VMS called global sections that can contain anything the designer/coder wishes to segregate, and MAYBE share with someone else. There are several versions of global sections that can be created through system service calls. They boil down to system, group global sections and process private sections and have secondary options, in some cases, of being permemant. The 'permemant' option means that until a system reboot is performed or the system service to delete the global section ($DGBLSC) is called the section will remain in memory ready for another process to map to it. Note that these sections are NOT SHARED among processors in a VAXCluster!!! Needless to say the SYSTEM version of global sections requires privs (SYSGBL), and the permenant section also needs privs (PRMGBL). Looking this through, the ability to use group level sections that are not permenant is a viable option to share data among various users. The only remaining problem area is to insure that your UAF record has enough quotas (PGFLQUOTA among others), and having the SAME GROUP UIC number to use this feature. One way is to specify a data file that you already have as being the input to the $CRMPSC call with the appropiate switches and give it UNIQUE name. Beware the 'Demand_zero' option as it will erase any existing data in the file if the file does contain any meaningful data. Other users will essentially invoke the same call to the system service with the same set of parameters and the same UNIQUE name. If everyone uses the same call, then the case of who is the FIRST one in is a don't care situation. The FIRST time caller will get the status of SS$_CREATED while the follow-up people will get SS$_NORMAL. I have used this method to share data between programs written in FORTRAN and after solving some initial problems had no problems. The problems and the workarounds I have found are listed below. Note that these are with FORTRAN overtones, so the PASCAL people will have to convert to what is appropiate. 1. The EASIEST way to handle the ALIGNMENT of the global section is to put it on a FULL PAGE boundary, compliments of the LINKer. This serves two purposes. The first being the mapping is slightly better for this sort of thing when the start of the section is on a full page boundary. The second is that it is very easy then to have the section map to a disk file and keep the '512 byte' outlook when the debugging gets tough and the dumps of the disk file are staring you in the face. This is done through the LINKer in the '.OPT' file by defining the characteristics of the Program Sections (PSECTS) that you need to accomplish this. To also ease the problem here do yourself two favors. First, only have one common per global section and give it a unique name. Second, create ANOTHER COMMON with the same unique name but having a suffix of '_AAAAA'. There need only be a single variable in this second common and it need never be referenced in the program. It is serving a LINKing problem only. The typical line in the .OPT file would look like the following. PSECT_ATTR=XXX,PAGE,NOEXE,RD,WRT,GBL,SHR PSECT_ATTR=XXX_AAAAA,PAGE,NOEXE,RD,WRT,GBL,SHR where XXX is the name of the PSECT containing the COMMON that is to be shared among the various users. By specifging the .OPT file you are OVER-RIDING the compiler generated specifications for these sections. The question to ask now is WHY create a SECOND common with the funky suffix?? The answer lies in the way the LINKer does its thing. All the names of the PSECTS are gathered together and placed in alpha order, by default, so the first thing that the '_AAAAA' section does is IMMEDIALTELY FOLLOW the PSECT containing the common you want to share. The call to the $CRMPSC service can use as the address reference points the first variable in the 'XXX' PSECT as the starting address and the first variable in the 'XXX_AAAAA' as the ending address. This puts EVERYTHING on 512 byte incrementals and its all set for mapping to a disk file. The '_AAAAA' section also provides a means to eliminate a portion of a previously mapped OR non-shared section of your program from being OVER-WRITTEN as a result of the mapping of the global section to a disk file. This latter was a problem that I spent the better part of a week seeking the cause, then the solution for. 2. A VERY good reading of the LINKer manual is in order for anyone interested in doing this type of thing. The information is well layed out and clearly detailed, although the first, and maybe the second times will be with clouds overhead. Hope this is helpful in the effort to share data between programs, and suffices as penance for my earlier suggestion of other means to share data. :-) pdc Paul D. Clayton Address - CLAYTON%XRT@CIS.UPENN.EDU Disclaimer: All thoughts and statements here are my own and NOT those of my employer, and are also not based on, or contain, restricted information.