Run time debugging of bshell (ttstpbshdebug)

The Debug on BW Message attempts to stop the current process if the process is compiled in debug. This feature will allow the programmer to determine where and when a BW message is generated.

Sends Bshell messages normally displayed in the BW message window also to the bshell trace file.

It is possible to specify a trace level to allow granularity of tracing. This allows better control over the reproduced amount of data. There are four trace levels. Each subsequent level provides a greater amount of detail. The levels are 0, 1, 2, and 3.

Example with the following tracings enabled: “Show object information” (-dbgobj) “Show Symbol Loading” (-dbgsym) “Program Flow” (-dbgflow):

Tracelevel 0: This will give information about the allocated memory per object/function.

Tracelevel 1: By using this trace level, you can determine the number of bytes used for static allocation using declaration (as opposed to dynamic memory allocations with alloc.mem() ). In this situation, tracelevel 1 prints the size of the bytes of the types, including the external types. So, tracelevel 1 specifies exactly for each symbol (variable) how much memory is allocated.

Tracelevel 2: When using tracelevel 2, the local and static symbols allocated are also shown. The names of the local and static symbols are “optimized away” by the bic compiler. At level 2, it becomes clear where and how much symbol memory is allocated for local symbols, external symbols, and for function arguments, (no function argument symbols).

Example with -dbgfun in combination with -dbgcpu:

The functions in LN have globally two levels of the functions: 3GL/4GL functions. bshell functions. The 3GL/4GL functions are covered with -dbgflow. The bshell function trace is covered with -dbgcpu, -dbgfun and the tracelevels.

Tracelevel 0 - This only prints the bshell functions.

Tracelevel 1 - Prints the bshell functions with parameters and its return value. - The error value “e” is also printed when modified within the bshell.

Tracelevel 2 - This level includes the symbol names, when available. - The error value “e” is also printed when modified within the bshell.

Tracelevel 3 - This level prints the source line number with the source name when the object is in debug. - The error value “e” is also printed when modified within the bshell.

If this check box is selected, the Bshell log file is not deleted on exit of the Bshell.

Add time stamps to Bshell log output.

The name and path of the ASCII logfile, by default $BSE/tmp/bshell.<pid>. This field is readonly. The path and file name of the log file can only be set in the BW configuration using the option -logfile.

This option will give information about the Bshell functions used. This option must be used in conjunction with -dbgcpu. Dbgfun only will give the object that is started, with the pid of that object. By adding –dbgcpu, the bshell function who is called in that object is logged in addition. If a new object is started, this will be put in the file. For old objects, the pid will be used. The functions that are used are only bshell functions and not the functions of applications.

This trace option switches the debug version of the bshell CPU on. The bshell cpu is the kernel of the bshell, executing all kind of tasks. Especially in case of bshell problems, this tracing can be useful. This option is used in combination with other loggings.

This option logs the Bshell VM CPU instructions. Only for very experienced bshell users.

This option logs the stacktrace for each 3/4GL function, and is used in combination with -dbgcpu. In case the 3/4GL object is not in debug mode, the stacktrace will only show internal 'IDs' instead of function names.

Trace information regarding getting and putting variables. A 3/4GL program can request a variable from another process using get.var(). And a 3/4GL program can assign a new value to a variable of another process using put.var(). These actions are logged using this trace option.

Using this Debug option, the 3GL function flow, with function names or numbers, and object names are logged. This information gives you insight into how the program flow was, and which functions were called from which place. In case the objects are compiled in debug mode, the function names themselves are logged, otherwise function numbers are logged.

This option logs the JavaVM integration actions.

This option logs the information of the objects that are used. First, we will get the object’s name and the pathname where it is stored. With this option, you can see which version is used and then a check can be done to see whether this is the latest version that must be used. Then, there is also some information on the object such as release number and revision number. This information is set in the object during compilation. Furthermore, we have some information about the number of bytes used within the object.

This option is used to see where the objects are loaded from; disk or memory. On UNIX, all objects will first be loaded from disc. If they are used again, you can load them from memory. On NT, the objects will stay in memory. Only after a fresh start of Windows, the objects will be loaded from disc. This only applies to objects that are in the $BSE/lib/srdd_init file. In this file, you can enter which files must be loaded in memory.

This option logs information about Triton Super Set.

The multibyte enabling has been implemented in LN by means of the Triton Super Set (TSS), which is a collection of character sets. TSS accommodates all multibyte character sets in a single package. TSS includes both ASCII character sets and multibyte character sets, such as Japanese, Chinese, and Hebrew. To distinguish between, for example, Japanese and Chinese, TSS consists of planes, each of which holds a 64 KB-size character set, or 256 pages of 256 characters.

Logs the user data input that is handled by function data.input(). like the next command (n) in the “general maintenance session” (ttaad4100).

This trace option shows all resources loaded by the bshell. Resources are coming from environment variables set. From files such as $BSE/lib/default/all,$BSE/lib/user/u<username> and so on.

Tracing of the bshell expressions as used in expr.compile/l.expr/d.expr/s.expr$ calls (refer to the ERP Enterprise (LN) Programmer's Guide).

Show Symbol Info allows a finer tracing when tracing the allocation and reading of symbols.

Remark: when having Show Symbol Info set only, it logs nothing, it only makes sense in combination with other loggings.

In comparison with “Debug file access” (-dbgfdev), this tracing only shows the successfully opened files.

With this option, the files to be accessed are logged. The place where the files should appear is given, also, when an error occurs, like a read permission, this error is logged. It is possible to get an error 2 because the file does not exist, or an error 13, when the permission is not correct. By starting the LN menu browser, the bshell will look for files with default information, in the $BSE/lib/default directory. It is not necessary to have these files, so it is not always necessary that the errno is 0.

LTS provides a mechanism to store translatable software components, such as labels, questions, and messages separate from language-independent software components, such as form and report designs. For example, a sales order entry form contains only an identifier to a referring label and will be used by all system languages. The translated labels will be added only to display the form.

This option shows from which location the labels are read.

It is visible by the first character of each label that is displayed in this session (ttstpbshdebug), see list below:

Note: No further information is stored in the Bshell log file.

This trace option logs information about scheduling of processes by the bshell. This option is only interesting in case of low-level problems regarding process scheduling.

This trace option gives information that occurs with the processes. When a session is started, this is a new process in the bshell. Processes can be activated, sleeping, killed, or can communicate with each other (send_bms and receive_bms). All this information regarding the processes is logged with this option.

This option logs the database drivers and parameters currently in use.

This option logs all kind of database actions such as Insert, Update, Delete, Commit, and Abort. The actions which are requested by the client, to be executed by the server (database driver), are specified by using messages.

The LN client sends commands to the server, and the server sends the results back to the client. In some cases, the server can ask the client for more information to carry out a command. In that case, the server sends an error back to the client and in some cases a list of required information as well. In most cases, the client sends the requested information to the server.

Messages of BDB_DEBUG=00002 can be identified by the first character:

An arrow to the right (->) means: ‘from client to server’. An arrow to the left (<-) means: ‘from the server to the client’.

The following message types are possible:

This option logs information on currently set locks.

This option logs the references between tables.

This option logs all tables using native storage format.

This option logs information about the database authorizations of the user. With the option BDB_DEBUG=02 the sending of the permissions is logged and with BDB_DEBUG=100 what permissions are send, is logged.

This option logs information on the opening and closing of cursors. As soon as a table must be accessed, a cursor must be opened.

Here is a summary of the BDB_DEBUG values that can be set:

If all BDB_DEBUG options are set, the resulting value will be: 00357

The BAAN_SQL_TRACE value 02000 logs the calls of internal SQL functions. In addition, it added a lot of information to the trace file. In case you are not explicitly interested in this information, do not use value 02000 to keep the trace file small and more readable. In case you are interested in the flow of a program, the result of this trace value will give you an indication of the executed queries and their execution flow. (Consider running the program in debug mode to get an exact overview of the flow of a program).

This option logs the LN database activities initiated from the Bshell.

For example, when inserting a record in the Price Lists (tcmcs0134m000) session, or delete some records.

This option dumps information about the enums used in the data dictionary when reading the DD.

This option does not work any more.

This trace option logs for each table the database server type and its parameters.