Since the contents of the database in a production client must always be consistent, there are particularly strict requirements for debugging in them:
Production clients do not have the value “T” in the CCCATEGORIE field of table T000.
● This is why the system must not execute a COMMIT WORK. What is particularly important is that all database changes can be rolled back in the event of a program termination. To ensure that this is possible, a dialog process converts to a debugging process. This process is assigned to the user for the duration of their debugging session. This is why no COMMIT WORK is executed by the system.
● To ensure that debugging activities cannot block the whole system, only half of all dialog processes can be used for debugging.
Since only a restricted number of dialog work processes can switch to debugging mode, you should exit the Debugger as soon as you no longer need it. Otherwise, you will unnecessarily block the work process.
In test clients, where data integrity is not so crucial, the number of dialog processes that are available for debugging is defined via the profile parameter rdisp/wpdbug_max_no. If another user want to debug the database, and the process cannot – therefore – convert to a debugging process, a COMMIT WORK must be executed after each step The process is then released again for all other users. The database changes cannot, therefore, be rolled back if a program termination occurs.