Macro> /LOGFILE

[Bob Hansen]

Thanks for the separate logging features in 7.1.18.
The initial macro log is properly recording all of the steps from called macros, even when stacked, into the log file when /LOGFILE is not used. And the logging goes to the /LOGFILE destination instead of the initial log when /LOGFILE is used.

But I initially needed help with /LOGFILE parameter with macros. The Help section mentions, but does not provide a sample of using /LOGFILE.

I tried the following with no success:
MACRO>path\macro.scp /LOGFILE
MACRO>path\macro.scp /logfile
MACRO>path\macro.scp,/LOGFILE
MACRO>/LOGFILE,path\macro.scp
MACRO>/LOGFILE path\macro.scp

The following syntax finally did work:
MACRO>path\macro.scp /LOGFILE=path\file.log

Although this does work, and provides the logging to separate files, it should be picking the log destination automatically. Right now, I must look up the defined destination of the log file by saving the current script, closing the editor, opening the properties of the called macro, copying to clipboard, closing properties, reopening the editor, and pasting in the /logfile value.

Suggested modifications:
1. Update the Help section to provide an example of the syntax.
2. Change program to pickup the existing value of the destination for the called macro from that macro's properties. Or allow /LOGFILE= to use defined destination unless a value is added.

[support]

Hi,

You must provide the log file using /LOGFILE=logfile

From the help file:

"You can override this using the /LOGFILE parameter to set a log file for the sub macro. "

And

"You can specify a log file for the macro by passing the LOGFILE variable:

msched.exe c:\scripts\my script.scp /LOGFILE=c:\mylogfile.log "

[Bob Hansen]

I guess it was just teminology, variables vs. parameters.

The help for MACRO shows syntax of "variables". I understood this to mean variables that would be passed to the called macro. The section dealing with variables discusses that as the usage for variables, they must exist in the calling macro.

The section dealing with /LOGFILE calls it a parameter, not a variable.

Although I did figure it out, and you have pointed out those sections, I still think the example syntax would be more helpful if it showed something like the following:

Macro>file_name [/variable=value|variable] [/variable=value|variable] ... [/LOGFILE=file.log]


I am not trying to be critical, but trying to be helpful.
===============================

But the calling and logging of macros from within macros is different from the command line option. In the Help for the Command Line Options it states:

It is not necessary to specify a log file if running a macro using only the macro name for a macro that already has logging enabled. In this case the log file settings for that macro will be used. However, if the LOGFILE parameter is passed it will override the macro's existing logging settings.

But when calling a macro from within a macro it will not use the defined logging destination. It does require a definition. Any chance that will be changed to be similar to the Command Line technique as I suggested in my earlier note?

Not only will it be easier to work with, but it will have consistent syntax where ever /LOGFILE is used. /LOGFILE will override the existing value in the defined properties.

Thanks again for listening.....

[support]

But when calling a macro from within a macro it will not use the defined logging destination. It does require a definition. Any chance that will be changed to be similar to the Command Line technique as I suggested in my earlier note?

Not only will it be easier to work with, but it will have consistent syntax where ever /LOGFILE is used. /LOGFILE will override the existing value in the defined properties.

Thanks again for listening.....

The trouble is I don't think that this would be possible due to the necessary isolation of the macroscript interpreter to allow compilation to work.

In the case of the command line, Macro Scheduler - the macro organizer if you will - can pass anything into the code interpreter, and knows about macro settings. The code interpreter on the other hand doesn't. So when calling a macro file from a macro things need to be made explicit and it isn't sensible/possible to start looking for Macro Scheduler settings.

However, points taken, and we'll certainly aim to make the documentation more obvious and perhaps there is a workaround that I'm not aware of that will enable pre-compiler functionality.

Thanks for your feedback.