[fa.info-vax] Detached processes

info-vax (03/26/83)

>From GEOFF5@SRI-CSL  Sat Mar 26 10:09:34 1983
Received: by UCBVAX.ARPA (3.331/3.17)
	id AA05829; 26 Mar 83 10:10:28 PST (Sat)
To: info-vax@SRI-CSL
Cc: tihor.cmcl1@NYU
Remailed-Date: 25 Mar 1983 2012-PST
Remailed-From: the tty of Geoffrey S. Goodfellow  <Geoff5 at SRI-CSL>
Remailed-To: Info-VAX@SRI-CSL.ARPA: ;

I guess I didn't supply enough details about that last question.
What I am doing is

$run /inp=TTC1:/out=TTC1:/proc=foo/uic=[1,4]/noauth sys:loginout

... with suitable privileges enabled.  Under release 2.x, it popped a
logged-in DCL at TTC1 [just for example's sake], now the same thing
comes up Username: on TTC1.  I wonder if the logged-in DCL was just
never supposed to happen under 2.x and they fixed it in 3.0?

One change we made under 3.0 was to set the TTY_PROTECTION in SYSGEN
such that you need SYSPRV to allocate a terminal line; could this 
have anything to do with it? I figured that a suitably privileged
process wouldn't worry about such things.

_H*
-------

info-vax@ucbvax.ARPA (09/13/84)

From: Jeff Jortner <jortner%lsu.csnet@csnet-relay.arpa>

	I am programming in VAX-11 C under VMS 3.6 and am trying to
have two detached processes utilize a shared image for common data.
I am able to make this work when I use subprocesses instead of detached
processes. If anyone has an answer for this problem, I would greatly
appreciate their help.
	Also, does anyone know why the linker( when generating shareable code)
says that an object module is not PIC when C is the source language?

						Jeff Jortner

rcb@rti-sel.UUCP (09/14/84)

	First, the real problem with using shared images for common
data, is that to use them globally, you must install them. Then, anyone
can link to the shared image and access it. Your problem is probably
that you are not installing it. A better way is use a global section
that is mapped to a file. If you make a structure that has all
the data that you want to share and declare a global instance of that
structure, it will be given it's own psect by the linker. Then, you
set the psect's attribute to page alignment in the linker options file.
When the program runs, the first thing that it does is to call
Create and Map Global Section system call to map a file onto the
memory that is occupied by the structure. This will automatically
unmap the normal virtual memory and map the file onto that area and
the pager will handle all the updates to the file. Also the file
can be changed by just calling the system routine with a new file
and it will write out the current data, map the new file in, and
all the processes linked to it will have the new data. The best thing,
however, is that the file protection is still in effect and you
can control who gets access to the data.

	Secondly, the image is not position independent because of the
way the compiler handles global variables. Each global variable is
allocated it's own psect with the attributes of overlay and share and
nopic. Any references to this variable are defined exactly the same
way. When linked, the linker resolves these references and everything
works nicely. Except if you want to do anything fancy, like pic
code or shared code images. Oh, well. If you want to do anything
like that, use a real language. Like Fortran, or Pascal, or
my personal favorite, the MIGHTY MACRO-32.

					Randy Buckland
					Research Triangle Institute
					...!mcnc!rti!rcb

info-vax@ucbvax.ARPA (09/16/84)

From: jeff@uw-june.ARPA (Jeff Scofield)