Craig,
Depending on the complexity of your SEARCH
requirements...
Since UNZIP is available in source form, you could create a version that does the search directly on the output. "Simple" matter of finding the final output stage and implementing a filter on the data stream.
That will save you a process creation and two lots of I/O processing (out of UNZIP and into SEARCH). Furthermore, since you're potentially avoiding writing any of the uninteresting text, you may reduce the overall time below your 11 minutes for the unzip alone.
If you don't want to modify UNZIP, another option is to create your own mailbox with whatever characteristics you think will help performance. Something like this:
program makemailbox
inputs: lognam,bufquo,maxmsg
$crembx(,chan,maxmsg,bufquo,,,lognam,,)
$hiber
end program
(may be simpler just to hard code the mailbox attributes)
$ SPAWN/NOWAIT makemailbox mymailbox max quo
$ SPAWN/NOWAIT SEARCH mymailbox whatever
$ PIPE UNZIP -c file > mymailbox
Notes:
The "PIPE >" command was easiest way I could find to redirect UNZIP output into the mailbox. It does not involve subprocess creation or use a pipe, so it's unlikely to have any negative performance effect.
The "makemailbox" subprocess needs to stay around until one of the other processes has opened a channel to the mailbox. It will remain indefinitely until killed or woken (SYS$WAKE).
The SEARCH subprocess will terminate at EOF of the UNZIPped stream. Issuing a second UNZIP against the same mailbox will put the main process into RWMBX because there is no reader.
No idea if this mechanism will be an improvement, try it and see!
A crucible of informative mistakes
