Using client-side logging
It may also be helpful to view server-side logs. See Using server-side logging. |
You may want to use client-side logging when access to the server is inconvenient, or when you have used server-side logging and seen differences between what the client program is passing and what the server log shows is being received. All xfNetLink .NET client errors are written to the Windows application event log, regardless of whether logging is turned on. Client-side logging, however, enables you to log other types of information in addition to errors.
To turn on client-side logging, use the xfNetLink .NET Configuration Utility to set the “logging” and “logfile” values in the application configuration file or set the environment variables XFNLNET_CLASS_LOGGING and XFNLNET_CLASS_LOGFILE. By default, client-side logging produces a separate log file for each class that instantiates a connection to xfServerPlus. The log files are named with the specified (or default) log file name, plus a date/time stamp so that you can differentiate them. If you would prefer that all connections write to a single log file, use the xfNetLink .NET Configuration Utility to turn on the “single log file” option or set XFNLNET_CLASS_SINGLELOGFILE. (See Creating and editing configuration files for instructions on setting these options in the config file.)
One of the advantages of multi-file logging is improved performance. Because only one process is writing to the file, it can remain open. With single-file logging, the file must be opened and closed because different processes are writing to it, and this slows performance.
The information included in the log depends on the options you select in the xfNetLink .NET Configuration Utility or set with XFNLNET_CLASS_LOGGING; see the Class Settings table for the available options. For the sample log below, we turned on all logging. “00046X” is the identifier of the class object writing to this log. Note that if encryption is enabled, the log displays a string of 10 asterisks instead of the packet data for encrypted methods.
00046X:created instance of syntst 00046X:configuration settings 00046X: host = elmo 00046X: port = 2356 00046X: connecttimeout = 120 00046X: initializetimeout = 30 00046X: poolreturn = False 00046X: logging = -1 00046X: logfile = c:\temp\xfnet.log 00046X: pooling = False 00046X: singlelogfile = on 00046X: xfNetLink .NET version = 10.3.1.1 ********************************************* 00046X:calling connect 00046X:host=elmo port=2356 00046X:scl=2 00046X:connecting to xfServerPlus on host=elmo port=2356 00046X:sending launch request packet 00046X:packet length=56 00046X:8***&**************Q6**3************************* 00046X:received launch response packet 00046X:packet length=52 00046X:4***&***,********Y*=***************************** 00046X:received acknowledgement packet 00046X:packet length=53 00046X:5***********13-JUL-2014 12:03:32;00 00046X:sending second startup packet 00046X:packet length=43 00046X:+***N000010.1.3.51;0;************* 00046X:calling method function_one 00046X:Parameters: 00046X: p1=This is an alpha string that will likely be truncated 00046X: p2=12345 00046X: p3=9876543 00046X: p4=9876543 00046X:sending method call packet: 13-JUL-2014 12:03:32 PM 00046X:packet length=107 00046X:k***Nxfpl_tst1;4;AL50#This is an alpha string that will likely be trunca;DE5#12345;ID7#9876543;DE7#9876543; 00046X:received method call reply packet: 13-JUL-2014 12:03:32 PM 00046X:packet length=19 00046X:****Rxfpl_tst1;000; 00046X:done calling method function_one