These are all good approaches, but the difficulty is often in trying to
collate the information on what is happening client side and server side:
that usually means poring through multiple log files, especially if you use
different client languages as we did in my last company.
Our approach was to build a global logging client that would display logging
messages from client and server in the same window (colour coded to make it
easier). That way we could watch what was going on in real time when
simulating events, rather than having to wait to close down the programs
successfully and then go through the logs afterwards.
The client components used COM to broadcast to the logger and the server
components used sockets. In that way they would just check to see if the
logger was running when they started up and begin to log if it was, or
bypass the logging if not (there's some magic number handling as well to
ensure it is a legitimate client!). No switches to turn on and forget to
turn off again.
I'll try to get an article on it for the next edition of Spectrum, deadlines
permitting.
Brian
----- Original Message -----
From: "Hona, David S" <[EMAIL PROTECTED]>
To: <u2-users@listserver.u2ug.org>
Sent: Friday, December 05, 2008 5:02 AM
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Note that the SYSTEM(9001) function call returns the runtime stack.
I use a generic logging subroutine that writes to a sequential file any
information I want to log:
call @debuglogger("Starting phase 1")
In debuglogger, it writes out timedate stamp, PID, @USERNO, @WHO, @PATH,
etc., etc. along with the desired message. We have a global common flag
to toggle it on/off or output to screen, as well.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Reynolds
Sent: Friday, 5 December 2008 1:23 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Interesting idea that.
As standard, all subroutine calls in our software add to a "Stack" and
their names are deleted from the stack when control is returned to the
calling level. It doesn't solve the debug issue, but has given me an
idea about tracing. I'm sure the code was originally designed for such a
purpose, it was just never implemented.
Dave
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Israel, John R.
Sent: 04 December 2008 13:31
To: 'u2-users@listserver.u2ug.org'
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Just chiming in on the debugging in a web page which might also help
here since you loose the ability to interact.
I have written a universal E-mailing program that can be called from any
UniData program. It will work with both simple text or HTML depending
on how much effort the programmer wants to exert.
There are several simple INCLUDES that store COMMON info so that I can
just plug this into any subroutine I want.
Starting with my top-most subroutine (the one called by Redback), I
INCLUDE my setup code and set a COMMON flag as either null (disable
debugging E-mail) or with the name of the ASP web page (enabling the
debugging E-mail).
At critical points, I test if the E-mailing flag is turned on, and if
so, create an E-mail with all the critical info I might want at that
point, then send the E-mail to myself. This E-mail includes the
initiating web page and all subroutines that have been called to get to
the current subroutine.
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
