Jon,

Good logging is important and it's nice to see the effort you put into it. You might want to check out the fMsg() UDF, which is specifically designed for message handling and logging.

One of the things that makes most coders avoid logging is that we often need it for debugging and - when used as such - makes us go back into the code to turn it all off. fMsg() can display messages all the time, when debugging is on ($DEBUG=1), or when debugging is at a specific level or below ($DEBUG=3 to display level 1-3 messages). It's also a lot of work to open/write/close, not to mention formatting the messages.

With fMsg(), you can use the following syntax to add multiple levels of logging:
 Code:
fMsg(Msg, LMsg, Nl, Mode, Opt, R, C)
All but the first arguments are optional, so fMsg('my message') is displayed on the screen and written with a timestamp to the log.

Usually, the first argument is used for display and logging. The second argument is a different message that's written to the log - sometimes you want a text message on the screen and an error code in the log.

The "Nl" arg is a Boolean that suppresses the CRLF so that you can write a message when an event starts and complete it with status when it ends, all on the same line.

The Mode value controls output and is a binary value.
- 1 - suppresses the log timestamp, useful to write multiple events to a line
- 2 - adds a timestamp to the screen message
- 4 - Displays only when the global var $DEBUG is not zero.
This can be used with the OPT value to specify that DEBUG must be greater than some value before displaying the message, allowing many levels of debugging to be placed in your code.
- 8 - Performs an "abend" - after displaying/logging the message, it terminates the script execution with the exit code specified by the OPT value. Used when a non-recoverable error is detected.
- 16 - Log but do not display on the screen.

I use Mode 20 extensively for debug logging, and use the following during development to see the messages on the screen:
 Code:
$ONSCREEN = 0  ; set to 16 for production - suppress screen messages
$MSG_LOG_= '\path\to\logfile'
$DEBUG = 4   ; very verbose debugging
fMsg('Startup message..)
; some code
fMsg('Log an event...', '', 0, 16) ; suppress on-screen display
; some code
; display a debug message
fMsg('Starting XXX process', '', 0, 4 + $ONSCREEN)
; display a debug message at level 2 or higher
fMsg('FuncName-VarX=' + $VarX', '', 0, 4 + $ONSCREEN, 2)
By setting the value of DEBUG via config parameters or command line args, you can control how many messages are logged during debugging, if any. Messages with Debug enabled are prefixed with "-DEBUG-" when writing to the log to distinguish from standard messages.

One comment on your original issue.. a few months back a client that uses our commercial login script complained of printer mapping errors, and each time the error was "The environment is invalid". We provided them with a custom release that offered more debugging detail. We found that, on about 4 of 100+ workstations, that the environment was indeed invalid - it was completely empty! Resetting the user profile had no affect, and the problem affected everyone who logged into the computer. Since this was consistent on specific machines, they wound up re-imaging those systems. It would have been nice to find the actual problem but the effort involved wasn't worth the time spent. The issue occurred only during logon. After the desktop loaded, the script could be run successfully and the environment was correct. You might want to add "SET >env.log" to the start of your login script to see the state of the environment during logon. It was hard to diagnose initially because everything looked correct when the admin logged in and looked at the system.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D