Using client-side logging

Note

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