"MCCORE::BOLTHOUSE@ti-eg.CSNET" (04/22/87)
If you want fast process startup time, there is no better way than to create processes in advance, and use mailboxes or global sections to communicate between them. This is what TPU does, for example, when you open a DCL window; the DCL subprocess hangs around until you exit TPU. Detached processes are another way of handling this problem. If you are passing lots and lots and lots of logical names and symbols, your SPAWN performance will suffer dramatically; you can help this by using the JOB and GROUP logical name tables in some cases. People have been grousing for years that 'VMS is brain-damaged' because spawns don't work like fork(). The appropriate solution depends upon what problem you're trying to solve...sometimes fork() works better than creating a new process, sometimes not. Oh -- if you use detached processes, and you don't care about having a CLI available, that's one of the fastest ways I know to get a process out there: $ run/det image-name.exe /input=xxx/output=yyy/quota-qualifiers... Using this, you don't have to map a CLI, set up a bunch of stuff, and go through LOGINOUT.EXE. It's probably the fastest way to do it from DCL. Of course, from an image (you can use C for this), use the SYS$CREPRC() system service to accomplish this. It's much faster that LIB$SPAWN for the unremarkable reason that's how LIB$SPAWN makes the process in the first place... Hope this helps. david l. bolthouse texas instruments defense electronics information systems VAX system support ma bell: 214.952.2059 csnet: bolthouse%mccore@ti-eg arpa: bolthouse%mccore@ti-eg.csnet disclaimer: nah. you didn't hear me say anything, did you...