I am running Kixtart in our school district. When a specific group runs the script, it takes a little longer than normal to complete. It's not a big issue, but it should be completing faster. I have encountered this in the past and the cause is usally a command mapping to an invalid or unavailable location. I was wondering if there was another way to identify the problem command other than simply looking through the script manually. I am guessing there is some type of logging that I could do but I don't have any expereince using this feature. If someone could give me a quick "how to" it would be appreciated. It would make my life easier and save my eyes from looking through countless lines in the script! Thank you.
#201562 - 2011-02-1003:10 PMRe: Identifying bad commands and logging
[Re: 2582]
MartMart KiX Supporter
Registered: 2002-03-27
Posts: 4673
Loc: The Netherlands
The easiest way to do this would be to start the script in debugging mode. This will step trough the lines one by one showing you what lines messes things up.
#201563 - 2011-02-1003:27 PMRe: Identifying bad commands and logging
[Re: Mart]
Glenn BarnasGlenn Barnas KiX Supporter
Registered: 2003-01-28
Posts: 4402
Loc: New Jersey
The fMsg() UDF can be used to write timestamped logging info to a file. With it, you can add messages before and after each mapping, allowing you to determine which connection is causing a problem. The timestamps will show how long each mapping takes, along with the result of the command.
Ideally, you'd be using a common UDF to map the drive connections, rather than many separate Use statements. If you don't, its easy to change.. convert the Use command to a fUse function
Code:
Use M: \\server\share
becomes
Code:
fUse('M:', '\\server\share')
and the fUse could be as simple as
Code:
Function fUse($_Drv, $_Share)
Dim $_Msg, $_Err
$_Msg = 'fUse:Mapping ' + $_Drv + ' to ' + $_Share
fMsg($Msg, '', 0, 20)
Use $_Drv $_Share
$_Err = @ERROR ; preserve result from USE command
fMsg('fuse:' + @SERROR', '', 0, 20)
Exit $_Err
EndFunction
The fMsg UDF will write to a log file defined by a global variable called $MSG_LOG_, but only if the global variable $DEBUG is non-zero. The last parameter - "20", prevents messages from displaying on the screen (bit value 16) and only if in debug mode (bit value 4).
Somewhere in the beginning of your code, add the following:
Code:
Global $MSG_LOG_, $DEBUG
$MSG_LOG_ = '%TEMP\LoginMessages.log'
$DEBUG = 1
Don't forget to include the fMsg UDF in your script! The latest version of fMsg can be obtained from the Kix UDF Library in the Resources section of my web site. After diagnosis, you can set $DEBUG = 0 to turn off logging - no need to remove the calls to fMsg.
Glenn
_________________________ Actually I am a Rocket Scientist!
