CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") (05/24/88)
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.
cfchiesa@bsu-cs.UUCP (Christopher Chiesa) (05/26/88)
In article <8805240319.AA07083@linc.cis.upenn.edu>, CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") writes: > Christopher Kempke has asked... [edited for brevity] > > > 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'll handle] 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. > I'm helping a friend write a program in which we want to do PRECISELY this same thing. However, I have a problem with Paul Clayton's answer to Chris Kempke's original question. Paul's reply, in part, states things like: > The basic problem that has to be dealt with in designing/coding installed > images is... > ... INSTALL the image with /SHARE, among other(s) ... Our problem is that we aren't able to INSTALL the image; we're non-privileged users trying to manage interprocess communication without the privs that make such things simple. Our system manager has previously mentioned to me that "within a group," users can share (something); would that be restricted to Mailboxes, or are Global Sections shareable between non-privileged users in the SAME GROUP? This points up one disappointing note about this group, from my (necessarily limited) point of view: most, if not all, the software hints, procedures, etc. listed here require privileges; I've NEVER been able to use any of the "mail file utilities" for example, as they assume access to things I can't get at, like the System-level VMSMAIL.DAT (?) file... Those of you who no- ticed my batch-queue Mail-answerer procedure may have noticed that it doesn't require privs to do its thing: it would've been ten times EASIER with privs, but I've been forced to learn to work without them. Is anyone else here in the "same boat?" (Ball State people need not answer.) If so, I'd like to know of any "workarounds" that let you do anything useful without privs. For in- stance, I can talk to other logins of MY OWN USERNAME using $BRKTHRU, and can send data that way by "trapping" the broadcasts and using them to pass command strings. Anyone else have any other klever kludges of this nature? Thanx for any replies; this should be interesting! Chris Chiesa -- UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa cfchiesa@bsu-cs.UUCP
CLAYTON%xrt.upenn.EDU%KL.SRI.COM%lbl%sfsu1.hepnet@LBL.GOV (05/29/88)
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." <CLAYTON@xrt.upenn.edu>
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.