The ObjectStore server can be setup to display debuggin and profiling information via activities. The ObjectStore client can report about the relvant network traffic.
The ObjectStore server can be started under Windows NT in two different ways: as a service and as a console application. The system control service applet helps start the service or - like in Windows NT - the command
net start "ObjectStore Server R6.3"
The command
Osserver -con
will be used as an application. There are to ways of making debug information get displayed. In case the server is supposed to run on the command line, the parameter "–d [1-9]" will be passed (9 provides most information). The output can be bypassed as usual. E.g.
Osserver –con –d 6 > c:\debug.log
In case the server gets used like a service, or the service cannot be stopped in the meantime, the debug mode can be switched during runtime via command "Ossvrdebug <Hostname> <Level>". The output can be found in file <%OS_TMPDIR%>\osserver.txt.
This type of a problem search is not documented. It results from the mail traffic with ODI. It can slow down applications significantly.
The environment variable OS_DEBUG_NETWORK needs to be set to 1.
For console applications, the output should be bypassed as usual. GUI applications display a message box for each line in a message box. To prevent this, the environment variable "OS_STDOUT_FILE" needs to be set to a file name. The network information will now be written into the file. If multiple applications are running on one client when displaying information, it is possible to use a part with the name "%d". Here, the process ID of the equivalent application will be used.
fileName GetManager(OBJECT) Call(SetHooks)
activates a protocol with all relevant ObjectStore activities via
InstantView®
Profiling. The caused database activities can be seen next to the InstantView®
statement calls and the received messages.
Another object manager function makes it possible to record access to objects of
certain classes:
fileName [ class1, class2, ..., classn ] GetManager(OBJECT) Call(SetAccessHook)
Here, the class name needs to be indicated as a string. If the function SetHooks
has been accessed before, it will be written into the already opened window.
Both funtions can only be deactivated when restarting the ClassiX®
systems.
Example:
Define(TestStmnt)
iterate { FillWindow };
Profile
„profile.log“[ „CX_PERSON“, „CX_STREET_ADDRESS“] GetManager(OBJECT) Call(SetAccessHook)
FindAll(CX_PERSON)
===> TestStmnt entered (10.24.19:134) CX_PERSON </hs/c:/classix/projects/classix.cxd | 32 | 0> accessed (inbound hook) CX_PERSON </hs/c:/classix/projects/classix.cxd | 32 | 118> accessed (inbound hook) CX_PERSON </hs/c:/classix/projects/classix.cxd | 32 | 1ec> accessed (inbound hook) CX_PERSON </hs/c:/classix/projects/classix.cxd | 32 | 2c0> accessed (inbound hook) CX_STREET_ADDRESS </hs/c:/classix/projects/classix.cxd | 32 | 390> accessed (inbound hook) CX_STREET_ADDRESS </hs/c:/classix/projects/classix.cxd | 32 | 4a0> accessed (inbound hook) CX_STREET_ADDRESS </hs/c:/classix/projects/classix.cxd | 32 | 5a8> accessed (inbound hook) ===> TestStmnt leaved, duration 551 ms CX_PERSON </hs/c:/classix/projects/classix.cxd | 32 | 0> committed (outbound hook) CX_PERSON </hs/c:/classix/projects/classix.cxd | 32 | 118> committed (outbound hook) CX_PERSON </hs/c:/classix/projects/classix.cxd | 32 | 1ec> committed (outbound hook) CX_PERSON </hs/c:/classix/projects/classix.cxd | 32 | 2c0> committed (outbound hook) CX_STREET_ADDRESS </hs/c:/classix/projects/classix.cxd | 32 | 390> committed (outbound hook) CX_STREET_ADDRESS </hs/c:/classix/projects/classix.cxd | 32 | 4a0> committed (outbound hook) CX_STREET_ADDRESS </hs/c:/classix/projects/classix.cxd | 32 | 5a8> committed (outbound hook)