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.
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.
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.
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.