For v11.17.0:

• New vendor variable ls_diagnostics_enabled, enabled by default.
• Message-based diagnostics is emitted only by POSIX license servers (Linux, Solaris, macOS, HP-UX and AIX).
• Whilst diagnostics will be generated from messages sent by legacy clients, these clients will not send session information.
• The Java client has limited diagnostics support - it will not send the SessionID or ProcessID
• Message-based diagnostics has limited support from lmadmin, specifically, heartbeat messages cannot be identified as coming from the lmadmin.

From v11.18.0:

• Diagnostics port listener is supported on Windows 10 from build 17093 and not supported on Windows 7 and Windows 10 earlier than build 17093.

Steps to Perform: 

• Build the default FNP toolkit for your native vendor daemon.
• Start the license server with a crypted license file.
• For demo, we will use ‘log2file’ executable to log the diagnostic messages for server-client communication.

                  Make sure that ‘log2file’ executable is built post toolkit build. If not then take a reference from v11.18.0 makefile and build the executable by                         running “nmake log2file.exe”

• Start the diagnostic Deamon logging by running the command (in a separate command prompt), as:

                    “log2file.exe lmgrd_diag.csv”

• Perform the checkout and checkin operation through few client calls (lmflex).
• Perform the lmstat on active server.

Now, bring the server down. Post that, navigate to the created excel sheet names ‘lmgrd_diag.csv’. It should have entries against client communication, as:

• This file logs the parallel client operation names under Component.
• Be advised about other options as “log2db.exe” & “log2port.exe”. Kindly refer to documentation for more details about these executables.

Diagnostics Filtering

Filtering can occur pre- or post-message-based diagnostics is persisted. The former kind of filtering might typically occur in order to save disk space, whereas the latter would typically occur when searching for the source of capacity overload in the server.

An example of pre-persistence filtering is available in the log2db.c sample. The command line...

 ./log2db -i -d diag.db COMPONENT=^lc_check

... will only write records (aka diagnostic message rows) to the database that match the COMPONENT=^lc_check regular expression - that is, only rows corresponding to messages generated from lc_checkout or lc_checkin API calls.

Filtering can occur on any field or on any combination of fields. 

API based message diagnostics customization:

A single row of diagnostics data corresponds to one message sent to the license server. However, many client API calls, such as lc_checkout, comprise several messages. In order to be able to trace all the messages from a particular lc_* call instance, FNP clients now have the concept of a session - each diagnostics row has a SessionID. By default, a session exists for the duration of any one lc_* call. However, it may be that producers want to define a session as encompassing multiple lc_* calls. For this purpose two new APIs are provided

• lc_diagnostics_start(unsigned int value); // max 28-bits value
• lc_diagnostics_end();

These optional APIs are intended to wrap a section of code in a lmflex client that a producer wishes to identify as a session. The value will be reported as Component= USER and Info=hex(value) in diagnostics. The SessionID used for all messaged wrapped by lc_diagnostics_start/end will be constant and based on the value.

Message-based diagnostics are in addition to and separate from the diagnostics already being written to the server log.

Example of Implementation:

Client Implementation:

User-defined Info and SessionID

lc_diagnostics_start(10);
lc_checkout(lm_job, FEATURE, "1.0", 1, LM_CO_NOWAIT, &code, LM_DUP_NONE));
lc_checkin(lm_job, FEATURE, 0);
lc_diagnostics_end();