Article 4534 of vmsnet.internals: Path: nntpd.lkg.dec.com!pa.dec.com!decwrl!newsspool.doit.wisc.edu!uwm.edu!newsfeed.internetmci.com!news.mathworks.com!mvb.saic.com!macro32 From: Brian Schenkenberger Newsgroups: vmsnet.internals Subject: Re: "LIB$PUT_FOREIGN" for Alpha Message-ID: <0099EC66.1BB405E8.8@ALPHA.WKU.EDU> Date: Sun, 03 Mar 1996 08:44:33 CST Organization: Macro32<==>Vmsnet.Internals Gateway X-Gateway-Source-Info: Mailing List Lines: 86 carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes: >In article <4gved7$m8f@sneezy.icinet.net>, "Frank E. Noell" writes: >=Sorry, I guess my request was too brief. I need "LIB$PUT_FOREIGN" to >=place "foreign stuff" in the foreign area so that an image that would >=normally be run with a foreign command (from the DCL CLI) can be >=activated within another program - using the image activator system >=service $IMGACT. This is unsupported stuff. As DEC has changed the way >=the "foreign stuff" area is accessed, I want to be sure I am using the >=correct pointers so that it will not break with new VMS releases. > >Er, forgive me if I'm demonstrating my ignorance here, but if you use $IMGACT >(which is *NOT* a system service, but rather an executive routine), don't you SYS$IMGACT *IS* a system service. In fact, it's an executive mode system service. The SYS$IMGACT service vector issues a CHME on an Alpha and VAX to transfer to the service routine in executive mode. >lose the context of the previous image? OK, if you don't lose that context, >then just say so, and don't bother reading further. If you *DO* lose that The context would depend on what sort of image was being activated. I believe, from following the schetchy details of the original poster, that this person wants to have a program run, execute a DCL command, and return to the program run. >context, then why don't you, instead of using undocumented, unsupported >techniques, simply use LIB$DO_COMMAND, which is both documented and supported? >For that matter, even if $IMGACT doesn't lose the context, unless you need to >revert to the previous image context, LIB$DO_COMMAND would be the way to go, >wouldn't it? The problem with the LIB$DO_COMMAND (and the mechanism behind it) is that the command queued to the CLI will not be serviced until the user program terminates. If I may, I might have a "pseudo"-solution to the original poster's problem. Several years ago, I wrote a small ditty which could be activated by a DCL command. I called the command REPEAT. The purpose of REPEAT was to take a DCL command and reissue it until the user typed a CTRL-Y. For example: $ REPEAT SHOW TIME This would essential perform: $ 10$: SHOW TIME $ WAIT 0:0:1 $ GOTO 10$ Let me outline the general flow of the program and, if it's usable, I'll clean it up, "alphabetize" it, and post it. The program would be run (activated) by the REPEAT command. The program parsed the rest of the command line using the CLI$DCL_PARSE routine and the process's copy of the DCLTABLES via CTL$AG_CLITABLE. The command string was copied to the process common area CTL$A_COMMON. The program then builds a CLI service block specifying that the service is a command and passed the address of the command stored in the common area. Then, it issues a CHMS with the 'command' service code. Another CLI service block is built and this specifies the CLI CHAIN function to run the repeat code. The block has the address of the descriptor of the program name string. Then, it issues a CHMS with the 'chain' service code. When the REPEAT program terminates, the COMMAND is executed and then, the CHAIN service reactivates the REPEAT code. A simple state machine mechanism determines if the program is being a ctivated from the command line or via the CHAIN and take appropriate action for obtaining the command line. BTW- I add a 1 second wait in the program (for obvious reasons). VAXman - Say what you want/Say what you will/'Cos I find you think what makes it easier And lies spread on lies/We don't care/Belief is our relief/We don't care - Tears For Fears: the hurting/ideas as opiates -