Path: utzoo!utgpu!water!watmath!clyde!att!ihnp4!ucbvax!LBL.GOV!CLAYTON%xrt.upenn.EDU%KL.SRI.COM%lbl%sfsu1.hepnet From: CLAYTON%xrt.upenn.EDU%KL.SRI.COM%lbl%sfsu1.hepnet@LBL.GOV Newsgroups: comp.os.vms Subject: Re: Installed Image/Global Section Question With PASCAL Overtones... Message-ID: <880528165259.23e03746@LBL.Gov> Date: 28 May 88 23:52:59 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 73 Received: from KL.SRI.COM by LBL.Gov with INTERNET ; Sat, 28 May 88 16:50:22 PDT Received: from linc.cis.upenn.edu by KL.SRI.COM with TCP; Mon 23 May 88 20:19:50-PDT Received: from XRT.UPENN.EDU by linc.cis.upenn.edu id AA07083; Mon, 23 May 88 23:19:43 EDT Posted-Date: Mon, 23 May 88 23:20 EDT Message-Id: <8805240319.AA07083@linc.cis.upenn.edu> Date: Mon, 23 May 88 23:20 EDT From: "Clayton, Paul D." Subject: Re: Installed Image/Global Section Question With PASCAL Overtones... To: INFO-VAX@KL.SRI.COM X-Vms-To: @INFOVAX,CLAYTON Christopher Kempke has asked the following question concerning the use of global sections for the purpose of sharing data between programs. > I'm looking for an example of the $CRMPSC system service called > from Pascal. (At least I think that's what I'm looking for). Here's the > problem: I want to have a bunch of identical images running in memory at > the same time, each capable of changing the variables, for cheap inter-process > communication. I rejected Mailboxes for this task because of the volume > of data that needs to be stored. I'm willing to worry about things like > race conditions on my own, but I need to figure out how to actually make > the Pascal variables shared. From reading the manuals, this appears to > be a global section I'm looking for. There might be an easier way to do this then through the $CRMPSC system service, the only question of the mechanics in doing it with PASCAL. The following sequence happened to be in FORTRAN, so you can try to convert to whatever is needed in PASCAL. The basic problem that has to be dealt with in designing/coding installed images is to insure that the characteristics of the various Program Sections (PSECTS) are setup to disallow sharing of portions of the image that should not be. This deals with the code segments, in order to prevent over-writing, and data segments in order to preserve the typical 'single threaded' nature of the programs we write today. My recommendation is to examine the characteristics of the PSECTS generated by the PASCAL compiler, for both the name and what they are set to. Then create an 'Options' (xxx.OPT) file to be used by the LINKer that sets the PSECTs characteristics to be SHR,GBL,RD,WRT for those PSECTS that contain the data you wish to share between the images that are running at the time. Then INSTALL the image with the /SHARE, among other(s) if desirable, to let VMS create the needed global section descriptors needed for image activation. The net result of this SHOULD be that all the users that are executing the image will be sharing the data among themselves. The following notes concern this approach. 1. It is the TOTAL responsibility of the application designer/coder to provide for the data sharing between multiple users and how to synch the contents of the variables between the users. 2. The data will ONLY last for the duration of the currently running images. Although this could conceivably be changed to have the last known contents be the 'starting' point for the next time someone runs the program after everyone stops running it for a time, by setting the '/WRITABLE' switch on the INSTALL command. 3. There are more usable options available to the users of the system service, such as backing storage, initialization from a disk file and others. It needs to be considered for a considerable number of applications. Have fun... 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.