Tips and Tricks for Uniface Logging 

During the development or maintenance of your Uniface application, you may need additional insights into what is happening under the hood. Fortunately, Uniface provides several increasingly detailed logging options to help you optimize your ProcScript or investigate issues such as why a userver won't start. 

The following tips apply to ide.asn, urouter.asn, userver.asn, and uniface.asn. The settings are also documented in the Uniface library. 

$PUTMESS_LOG_FILE 

This is the most commonly used log file setting. It writes the message frame to a file. $PUTMESS_LOG_FILE records what the Uniface process is doing in sequential order, with an emphasis on OS calls. This is very useful for determining what happened during the execution of your Uniface application. 

To activate, use the following setting: 

[SETTINGS] 

$PUTMESS_LOG_FILE=c:unifacelogsmyapp_putmess%p.log 

This will create a log file for the process you are running (uniface.exe, ide.exe, userver.exe, etc.), where %p is the OS process ID. Note that the process ID keeps each log file unique to each run of the program. This way, you can keep log information confined to the test you are performing. 

Another setting related to logging is $TRANSCRIPT_LOG_FILE, which can be used to copy the Transcript window contents to a file.

$IOPRINT   

You can set the type of information logged by using the $IOPRINT setting, which is used in conjunction with $PUTMESS_LOG_FILE. This setting is very useful for targeting specific information. 

[SETTINGS] 

$IOPRINT=64 

$PUTMESS_LOG_FILE=c:unifacelogsmyapp_putmess%p.log 

In this example, $IOPRINT is set to 64, which adds more detail regarding license-related operations. Another value could be $IOPRINT=255, which adds database-related information to the log, such as driver settings, connector queries, and responses. 

Note: The higher the $IOPRINT value, the more information will be logged. Keep this in mind when using verbose logging in a production environment. 

Experiment with different values and see what information is provided; it can greatly benefit your debugging and troubleshooting strategies. 

ProcScript Tracing and Profiling 

While $PUTMESS_LOG_FILE logs process and OS/IO events, it does not show you the actual ProcScript that was executed. 

ProcScript Profiling 

ProcScript profiling enables you to analyze performance problems by logging trigger processing time. For profiling, use $PROC_PROFILING. 

Settings for $PROC_PROFILING, $PROC_PROFILING_SEPARATOR, and $PROC_LOG_FILE can be set in the ASN file. For example, to enable ProcScript profiling: 

[SETTINGS] 

$PROC_PROFILING=true 

$PROC_PROFILING_SEPARATOR=Gold 

$PROC_LOG_FILE=c:unifacelogsprofiling.log 

ProcScript Tracing 

ProcScript tracing enables you to log the actual ProcScript execution, optionally enhanced with additional information. 

Tip: It is best not to use ProcScript profiling and tracing at the same time because ProcScript Tracing influences performance. 

For ProcScript tracing, use $PROC_TRACING together with $PROC_TRACING_ADDITION for more detailed information. For example: 

[SETTINGS] 

$PROC_TRACING=true 

$PROC_TRACING_ADDITION="Component: %%$componentname%%% / Status: %%$status%%%" 

$PROC_LOG_FILE=c:unifacelogsproctracing.log 

The log file will show you the executed ProcScript when running the application. This is very useful for determining whether your ProcScript changes work as expected. 

Dynamic $IOPRINT and ProcScript Tracing 

Sometimes applications are very large, and you may only want to trace the ProcScript for a certain part or component. ProcScript tracing can be started and stopped dynamically via ProcScript code. 

$IOPRINT, $PROC_TRACING, and $PROC_TRACING_ADDITION can be set in the ASN file or in ProcScript code. 

To limit the size of the ProcScript trace file, you can start and stop tracing via ProcScript (no ASN settings needed): 

In ProcScript: 

$PROC_TRACING=1 

$PROC_TRACING_ADDITION="%%$componentname %%$status" 

To stop ProcScript tracing: 

$PROC_TRACING=0 

Another good approach is to start ProcScript tracing on demand via user keys, which helps limit trace file size. 

At the bottom of your keyboard translation table, add, for example: 

^130^107 ^USER_KEY^150  

^130^108 ^USER_KEY^156  

Recompile your KTT or update your resources. See MSWINXDBG.xml with the keyboard translation table MSWINXDBG as an example. Import and compile the translation table MSWINXDBG and recreate the DOL if used. In your ASN, set $KEYBOARD=MSWINXDBG. 

In the <UserKey> trigger, add: 

message/info "User key %%$char pressed!!!"  

if ($char=150) 

 ;logging, tracing  

 $PROC_TRACING=1