Reporting issues

Use MFESdiags script to gather diagnostics files from all the regions in the PAC. This provides a lot of additional information, such as region exports, and so on.

Note: If you need to collect CTF or Aux tracing, then you need to set and collect this in each region of the PAC. Once you have collected the CTF or Aux tracing then you should stop this to avoid degrading performance.

If there are issues with dbfhdeploy, dbfhadmin, or configuration problems with getting files extracted, deployed, and you cannot recognize definitions in MFDBFH.cfg, then you can enable CTF using the config below:

# MFTRACE configuration file
mftrace.dest                      = textfile, binfile

mftrace.emitter.textfile#Location = .
mftrace.emitter.textfile#Format   = $(TIME) $(THREAD) $(COMPONENT) $(EVENT) $(LEVEL) :$(DATA)

mftrace.emitter.binfile#Location  = .
mftrace.emitter.binfile#Format    = $(TIME) $(THREAD) $(COMPONENT) $(EVENT) $(LEVEL) :$(DATA)

## Enable all tracing
## To enable tracing on specific switch, comment out #all line
## and uncomment the desired switch(es) below.

mftrace.level.mf.mfdbfh           = debug
mftrace.comp.mf.mfdbfh#all=true
mftrace.comp.mf.mfdbfh#api=true
mftrace.comp.mf.mfdbfh#config=true
mftrace.comp.mf.mfdbfh#database=true
mftrace.comp.mf.mfdbfh#datastore=true
mftrace.comp.mf.mfdbfh#fh=true
mftrace.comp.mf.mfdbfh#region=true
mftrace.comp.mf.mfdbfh#resource_locking=true

The resulting trace will contain information on any problem.

Note: You might need to use the annotations file located in $COBDIR/etc/mftrace/MF.MFDBFH.xml to interpret the trace.

If there are issues with loading files or with routines or calls failing, then you can enable RTS CTF in combination with CTF tracing. This will highlight what the routine is doing, that is, if your application is failing on a CBL_ routine, you could enable CTF tracing with RTS CTF to provide additional information on why the CBL_ routine is failing and whether it is accessing the database.

If the issues are occurring once a region has started, then in addition to the above you can use MFDBFH CTF, ES dumps/aux trace to investigate as any errors. If you are still unable to determine the cause, then capture mfesdiags and provide it to Customer Care.

Sometimes the MFDBFH CTF does not show up any immediate problems, or there might be issues on the database side that results an error code being thrown. In this cases, you can use third-party tracing in the form of ODBC tracing.

Note: You can only perform this type of tracing if you are using ODBC drivers to make the connection.

If you are using a direct connection to the database then you can look at the database trace.

For ODBC tracing, you can add the following to your odbc.ini for your main database connection:

Trace=1
TraceFile=/tmp/odbc.trace
Debug=1
DebugFile=/tmp/odbc.debug

Or you could add the following to your specific datastore connection definition, if you want to limit what is traced:

Debug=1
DebugFile=/tmp/odbc.debug

If you wanted to trace the ODBC connection to a specific datastore, you can use the following entry:

[PG.ASHNEW]
Driver = ODBC Driver 17 for SQL Server
Server = localhost
Database = MicroFocus$SEE$Files$ASHNEW
Debug=1
DebugFile=/tmp/odbc.debug

This logs information on what the ODBC driver is doing and whether it is failing.

Sometimes this does not necessarily show any problems as the issue may be on the database itself. In this case, you would need to investigate database diagnostic techniques specific to the RDBMS being used. This might be anything from low-level database tracing, such as SQL servers own trace, or investigating whether databases/tables have been created.

You can use the above techniques to find out which sql statements that are being made and specifically which are causing the issue. You can then run those in isolation on the database, that is, you can remove the Micro Focus elements from the scenario. If the dbfhdeploy is failing, you can use the MFDBFH scripts to determine the SQL statements and run them directly on the database.