Output Pathing

[tobarstep]

Is there a way - perhaps in the config file - to specify an output path for the *.msg file separate from the actual print file?

 

Right now I am invoking FusionPro from the command line via batch files, with the first line of the batch being the FusionPro command line sending the output file to various directories based on what the job is; the second line is a 1 second pause just to ensure the *.msg file completed; then the third line moves the *.msg file from the output directory to a more centralized directory for archival purposes.

 

That is working fine for us, but it would be nice if it was an option I could "set and forget" somewhere.

[Dan Korn]

You can set the "MsgFilePath" entry in the CFG file to specify a different directory into which the log file will be written. You can also set the "MsgFile" entry to change the name of the log file.

 

You might also want to look into using DL Queue to run your FP Server jobs.

[tobarstep]

Thanks for the cfg file suggestions. I'll have to give those a try. I may eventually give DL Queue a look, but I'm really happy with the flexibility I have at the command line for now.

[tobarstep]

To further this question, is it possible to completely suppress the log file?

My first thought was to set the MsgFilePath to something like /dev/null, which is just NUL on a Windows server I think. That isn't working for me though. Really I'd just like a way to suppress it rather than redirect it (in this particular case).

[Dan Korn]

To further this question, is it possible to completely suppress the log file?

My first thought was to set the MsgFilePath to something like /dev/null, which is just NUL on a Windows server I think. That isn't working for me though. Really I'd just like a way to suppress it rather than redirect it (in this particular case).

Hmm, that's a bit like asking if you can turn off that pesky alarm that sounds whenever your kitchen fills with smoke. In other words, you really don't want to turn off your log file, because it might contain some information that you need to know about, even if you don't look at it until some later point in time when you're trying to troubleshoot a problem. So no, there's no way to completely disable the log file. You could, however, use the "MsgFilePath" entry in the CFG file to write it to a temporary folder, which another process could periodically clean up. Or you can just ignore all the files in that temp folder.

[tobarstep]

Hmm, that's a bit like asking if you can turn off that pesky alarm that sounds whenever your kitchen fills with smoke. In other words, you really don't want to turn off your log file, because it might contain some information that you need to know about, even if you don't look at it until some later point in time when you're trying to troubleshoot a problem. So no, there's no way to completely disable the log file. You could, however, use the "MsgFilePath" entry in the CFG file to write it to a temporary folder, which another process could periodically clean up. Or you can just ignore all the files in that temp folder.

 

More like it's a very simple file that gets run hundreds of times a day. It would be nice not to have to clean up the log files. Was a simple question. No need for sarcasm.

[Dan Korn]

More like it's a very simple file that gets run hundreds of times a day. It would be nice not to have to clean up the log files. Was a simple question. No need for sarcasm.

Sorry, I wasn't trying to be sarcastic, just practical. I guess I'm just not understanding why it's so important to you to completely suppress the log file. It seems to me that what you're gaining in terms of maybe saving a few megabytes of disk space is not a good tradeoff with what you're potentially losing in the ability to track issues. But that's just my perspective as a developer.

 

Anyway, if you're running the job hundreds of times a day and you don't want to have to clean up all the log files, you can simply set the "MsgFile" and "MsgFilePath" entries in the CFG file so that the same log file is overwritten every time.

[tobarstep]

Sorry, I wasn't trying to be sarcastic, just practical. I guess I'm just not understanding why it's so important to you to completely suppress the log file. It seems to me that what you're gaining in terms of maybe saving a few megabytes of disk space is not a good tradeoff with what you're potentially losing in the ability to track issues. But that's just my perspective as a developer.

 

Anyway, if you're running the job hundreds of times a day and you don't want to have to clean up all the log files, you can simply set the "MsgFile" and "MsgFilePath" entries in the CFG file so that the same log file is overwritten every time.

 

Just trying to conserve where I can. We run a lot (I have 14 licensed FP server instances at my disposal) of different jobs. In a week's time I get 10000+ log files. Some jobs are 1 page/1 record merges that occur quite frequently with minor changes in the data. Log files are not hugely important for them.

 

I like your suggestion of overwriting though. I've been using the MsgFilePath. I didn't realize there was a MsgFile entry as well. They don't appear by default in my CFG files. I will have to try that.