MANAGER@SMITH.BITNET (Mary Malmros) (03/11/88)
I am looking for a system service or run-time library routine that will allow me to execute a second image. I want to do this in such a way that the flow of control will pass entirely to the second image, and will return to the first image at the calling point after the second image completes. Neither CREPRC nor LIB$SPAWN seem to do this, which makes sense since their purpose is to create another process altogether. I just want the SAME process to start executing a second image. I'm sure I'm overlooking something obvious... Thanks much. Mary Malmros Systems Manager Center for Academic Computing Smith College Northampton, MA 01063 (413) 584-2700 x3073 MANAGER@SMITH.BITNET
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (03/13/88)
I am looking for a system service or run-time library routine that will allow me to execute a second image. I want to do this in such a way that the flow of control will pass entirely to the second image, and will return to the first image at the calling point after the second image completes. Neither CREPRC nor LIB$SPAWN seem to do this, which makes sense since their purpose is to create another process altogether. I just want the SAME process to start executing a second image. I'm sure I'm overlooking something obvious... LIB$DO_COMMAND LIB$RUN_PROGRAM -- Jerry
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (03/13/88)
> I am looking for a system service or run-time library routine that > will allow me to execute a second image. I want to do this in such > a way that the flow of control will pass entirely to the second image, > and will return to the first image at the calling point after the second image > completes. Neither CREPRC nor LIB$SPAWN seem to do this, which makes sense > since their purpose is to create another process altogether. I just want the > SAME process to start executing a second image. I'm sure I'm overlooking > something obvious... First, I have to complain about your nomenclature: when you "chain" an image, control passes entirely from the image you're currently running, and when the "chained" image exits, control reverts to the OS (in the case of VMS, generally DCL). To do what you want to do, the image to be invoked must be sharable, and you invoke it by using LIB$FIND_IMAGE_SYMBOL, then branching to the entry point you want to use.
rang%cps45x@CPSWH.CPS.MSU.EDU (Anton Rang) (03/14/88)
The LIB$DO_COMMAND run-time library routine will let you pass a command to DCL to be executed. It won't do what you want, though, because it causes your (user mode) program to exit first (control flow will not return to the first image). There is an undocumented system service--I forget its name, but it was in the STARLET file a while ago anyway--which maps another image into virtual memory. I've seen one or two programs which use it, but never done anything with it myself. This would probably work (though image initialization etc. might be screwed up). As a last resort, look in the fiche at DCL to see how it does it. Of course, it's running in supervisor mode, but... Anton Rang Graduate student, Michigan State All opinions & mistakes are my own.
RMCEWEN@RCCA.BBN.COM (Regis McEwen) (03/14/88)
>> I am looking for a system service or run-time library routine that >> will allow me to execute a second image. I want to do this in such a >> way that the flow of control will pass entirely to the second image, >> and will return to the first image at the calling point after the >> second image completes. Neither CREPRC nor LIB$SPAWN seem to do this, >> which makes sense since their purpose is to create another process >> altogether. I just want the SAME process to start executing a second >> image. I'm sure I'm overlooking something obvious... >LIB$DO_COMMAND >LIB$RUN_PROGRAM > -- Jerry Neither one of these RTL routines will accomplish what you want. LIB$DO_COMMAND/LIB$RUN_PROGRAM will execute the command/program, respectively, then stop, immediately, *never* returning you to the calling program unless there was an error executing the call. (Assuming, of course, you have appropiate error handling). This is documented in the RTL manual. $CREPRC/LIB$SPAWN will do this, but, as you pointed out, will create another process, sub-process or possibly detached if you specify a UIC in $CREPRC. What you want *used* to be available with pre-VMS V3.? called LIB$EXECUTE_CLI. The only other "unsupported" way to do this, is to build your own calling stack and make a call to SYS$CLI. -Regis
BARMSTRO@carleton.EDU (Pod Stolom Consulting) (03/15/88)
Mary Malmos asks about chaining images such that the original
image will be resumed after the second image terminates, and
will be resumed at the point where the second image was called,
all using a single process.
My understanding of VMS process control is that there is no way to do this, at
least not one that already exists. You would need to copy the whole process
header (or most of it) to memory somewhere in physical memory before doing the
image initialization for the second program and then have some way of copying
this information back into the process header after the image rundown for the
second program, much like pushing and poping stack frames before and after
procedure calls. The process header would have to be stored in physical memory
because the real memory for the first image would be wiped clean when the
second program initializes. Since the rundown of the second image would again
cause real memory to be wiped clean, you would have to write a _third_ program
to move the physical copy of the process header back into memory, including all
the pages in the working set, and run the first and third program in a command
procedure. Access to the process header is ugly, and may not suffice to
recreate the status of the original image. Furthermore, the format of the
process header will inevitable change with VMS 5.x.
This is all assuming that you are running compiled images. An interpreted
environment would behave quite differently.
There have been many occassions when I would have found this ability very
useful. If I overlooked something in my own searches, I would be delighted to
hear about it. I shan't be holding my breath, however.
Disclaimer: I may not have the _vaguest_ idea of what I am talking about.
+-----------------------------------------------------------------------+
| Borden Armstrong Computer Center |
| System Manager and Carleton College |
| Academic Programmer/Analyst 1 North College Street |
| Northfield, MN 55057 |
| barmstro@carleton.edu U. S. A. |
| ...!umn-cs!stolaf!agnes!ccnfld!barmstro (507)663-4277 |
+-----------------------------------------------------------------------+sqkeith@csvax.liv.ac.uk (03/15/88)
In article <8803130859.AA26863@ucbvax.Berkeley.EDU>, MANAGER@SMITH.BITNET (Mary Malmros) writes: > I am looking for a system service or run-time library routine that > will allow me to execute a second image. I want to do this in such > a way that the flow of control will pass entirely to the second image, > and will return to the first image at the calling point after the second image > completes. Neither CREPRC nor LIB$SPAWN seem to do this, which makes sense > since their purpose is to create another process altogether. I just want the > SAME process to start executing a second image. I'm sure I'm overlooking > something obvious... LIB$FIND_IMAGE_SYMBOL (I think that's the name) is the routine you want. It takes the name of a shareable image and a global symbol name and returns its value. In doing that, it maps that image into your process space and activates it. You can get a number of symbols from the image and use them as the addresses of procedure entry masks from which you can issue the library routine versions of CALL_S etc.. I'm not sure whether the image is unmapped once you have finished with it - or how you signal that you have finished with it. Hope this helps, Keith Halewood UUCP: {backbone}!mcvax!ukc!mupsy!liv-cs!sqkeith Arpa: sqkeith%csvax.liv.ac.uk@nss.cs.ucl.ac.uk Janet: sqkeith@uk.ac.liv.csvax
SWANGER@AUDUCVAX.BITNET (03/16/88)
> I am looking for a system service or run-time library routine that > will allow me to execute a second image. I want to do this in such > a way that the flow of control will pass entirely to the second image, > and will return to the first image at the calling point after the second image > completes. Neither CREPRC nor LIB$SPAWN seem to do this, which makes sense > since their purpose is to create another process altogether. I just want the > SAME process to start executing a second image. I'm sure I'm overlooking > something obvious... According to the VAX/VMS Run-Time Library Routines Reference Manual, the default action for LIB$SPAWN is to wait until the spawned command is finished before returning to the calling program. For example, if you wanted to execute the program SCULLEY.EXE from within the program OLSEN.EXE, and then wanted to continue running OLSEN at the next command when SCULLEY was finished, you could use the following command in your OLSEN source code (Fortran example given): istat = lib$spawn('RUN SCULLEY') When this command is executed, OLSEN will pause until SCULLEY is finished running. Then OLSEN will continue. --------------------------- JCL - The Big Lie ---------------------------------- David Swanger Academic Computing Services 200 L Building Auburn University, AL 36849 Telephone: 205-826-4813 |-----------------------------------------| | | SWANGER@AUDUCVAX (BITNET address) | My opinions are my own ... etc. | | | --------------------------------------------------------------------------------
vtcf@NCSC.ARPA (Williams) (03/16/88)
There is a system on the net that is used for distributing mathematical software by electronic mail. They have various benchmark programs and a summary of timings for Linpack benchmarks. To obtain an index of the system, just send a one-line message to "netlib@anl-mcs.arpa" as follows: send index This will give you a general index, with instructions on how to use netlib. To get an index of the benchmark programs, send the message send index from benchmark These requests can be send in one mail message, you just have to specify one request per line. I hope this helps, we got Dongarra's Linpack and Whetstone benchmarks this way. (Hope I didn't cause netlib to get flooded with requests!) Tom Williams vtcf@ncsc.arpa