|
| Discussion | |
From: mda
Keywords: Querier, Suggestion
Remote Name: 24.147.232.222
Remote User:
Date: 02/07/01
Time: 23:07
This is a very sensible optimization for BTCrit, but the concensus seems to be that it's not urgent, because it's a relatively small, fixed part of the overall job. However, since BTCrit has mushroomed to its present huge proportions, I can see how the extra delay is getting to be a big annoyance, especially if you're running a lot of otherwise small jobs. Anyway, I think you've got the right idea: create one or more special records as part of the saved state, which your shell program can extract directly from the metafile to support the non-interactive Run action without ever instantiating the form. You don't really need to introduce any new form properties for this, just a metafile record that looks like a piece of saved state and doesn't cause any trouble when the state is restored. You could use a comment, for example, where the first character is a "*" and the rest of the cmdline is the value of the btcrit result expression. You would assign a distinctive sequence number to this record (#define macro recommended), so that the shell's Run logic would know where to look. Similarly, you would need to take care of any other global variables that btcrit is expected to return, whatever your current conventions are about that.
A few things to watch out for:
- choose reserved sequence numbers that don't conflict with any other usage
- consider the ramifications of any input parameters or global mvars that can affect the result of btcit
- attend to error handling issues: failure should be clean and follow conventions that allow Querier to fail cleanly, so that Job Control can take appropriate action and continue.
I'll deal with the question of XFormDBF separately, in its own forum. (There are significant differences.)
|
|
|
|
| Contents | Discussion | |
|