Monitoring subroutines for errors in d3/win
David Knight
I am wondering if there is a 'better way' to monitor subroutines for
errors which are normally not 'seen' onscreen; since any subroutine's
screen output is only 'seen' by the internals of designbais; and so
one could be blissfully unaware of logic & other errors such 'Array
subscript out of range'; 'Variable not assigned a value, zero used'
etc that all come out of d3/win [presumably] to std.out [that is, the
screen]?
I spent a particularly frustrating amount of time trying to debug for
exactly this reason: I could not 'see' any errors generated by my
subroutine.
Now, to my knowledge, there is no way in d3/Win to 'intercept' any
unexpected error, of god-forbid; debug abort to another device
[perhaps there is, but I'm not aware of one]; so the only way I found
was to figure out what d3 port designbais was 'talking' through [via
LISTU] and using a suitable terminal emulator logged onto another
account issue the d3 command 'tandem <PIB>' where PIB is the port
number you want to monitor.
This seemed to work fine, albeit a bit kludgy; but at least I could
'see' what is going on.
FWIW using this method, and moving around simply in the db toolset, I
monitored the following error from inside db:
[B10] in program "DBI.G.DETAIL", Line 3519:
Variable has not been assigned a value; zero used.
[B10] in program "DBI.G.DETAIL", Line 3519:
Variable has not been assigned a value; zero used.
This is exactly the sort of issue I'm talking about, and our friends
at db need to resolve this bug; but my point is this:
1. My experience [when I ran a very buggy s/r] is that such errors
dramtically slow down the system [I'm guessing db is having to handle
and then 'discard' this output?]
2. It eventually leads to a failure of that session, requiring a
restart of the session via the session monitor [not a good thing if in
a live environment!]
3. One could easily miss these errors even when degugging via test
data because one is not aware of these obscure issues. From the above
example, our friends at db were not aware of this one!!
What do others do? Am I the first to spot this? Is there some way to
'trap' all 'unexpected' output from a d3 routine so that it is goes to
[say] a log file?
Sorry for the long waffle, but I reckon this is a fairly serious
issue. What do others think?
Cheers,
David
David Knight
[B10] in program "DBI.G.DETAIL", Line 3519:
Variable has not been assigned a value; zero used.
[B10] in program "DBI.G.DETAIL", Line 3519:
Variable has not been assigned a value; zero used.
[B25] in program "DBI.G.DETAIL", Program 'PATIENTS%PAT%DERIVED%PRIVACY.WK' has not been cataloged.
Now, the first two are the same errors I spotted when simply navigating to 'Run a form'; but when I do actually run the form, in the browser it hangs. Now we know the reason why:
DBI.G.DETAIL has tried to run a routine, which is not catalogued and aborts! Rather ungraceful; which raises the point I am making. How would one have known had I not been monitoring the output?
Further, when I look at the subroutines created by the code snippet feature of db, the item names are delimited with a double percent sign; that is
PATIENTS%%PAT%%DERIVED%%PRIVACY.WK
The routines, found correctly in DBICODEBLOCK, and successfuly migrated across from UV, are all there, flashcompiled and catalogued; but do not 'match' what db is looking for.
Is suspect this an issue to do with UV. I vaguely recall something about UV's handling of percent signs as delimiters and how that was a problem; so perhaps this is a migration issue [Rick - can you comment, please?]; but further given that the inbuilt db editor does not work correctly on d3/win; if the 'logic' for handling the translation in/out of filenames is built into that editor; where does that leave me in this case?
I will try renaming and routines, which may get me out of this immediate issue, but does not help me in an ongoing fashion. Or am I missing something here?
Cheers
David
Tony Gravagno
logto dm
create-file runtime-errors 1 1001
Now, whenever you suspect is a BASIC runtime error, use list-runtime-errors to see the info. The dict is automatically created with the file.
Be sure you delete the file or monitor/prune it. It can grow uncontrollably and affect system performance as more items get added. I found a system that had ground to a halt because this file was created at 1,1 and had millions of records (in overflow). You could have a phantom e-mail you if that file is not empty, and maybe clear records older than x days (as part of other system monitoring)…
HTH
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
remove.pleaseNebula-RnD.com/blog
Visit http://PickWiki.com! Contribute!
David Knight
Dick Thiot
You will only want that file there when you are checking for errors. You should probably delete it otherwise or have a process that on a regular basis clears the file. It can cause systems to become slow for "no apparent reason" and often the file is forgotten and thus fills up with data well beyond its allocated size.
Dick
--To view this discussion on the web visit https://groups.google.com/d/msg/designbais-forum/-/B4aF5rUU5YYJ.
You received this message because you are subscribed to the Google Groups "DesignBais-Forum" group.
To post to this group, send email to designba...@googlegroups.com.
To unsubscribe from this group, send email to designbais-for...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/designbais-forum?hl=en.
Bobby Worley
From: Dick Thiot <dick....@gmail.com>
To: designba...@googlegroups.com
Sent: Saturday, May 12, 2012 12:13 PM
Subject: Re: Monitoring subroutines for errors in d3/win
David Knight
On Sunday, May 13, 2012 3:26:53 AM UTC+10, Bobby Worley wrote:
is the runtime-errors file a function of d3 or designbais? In other words, will it work for us users on AIX/Universe?Another debugging option is running DBI.RUN.LAST at tcl right after a browser failure, it has helped me in the past.
From: Dick Thiot
Sent: Saturday, May 12, 2012 12:13 PM
Subject: Re: Monitoring subroutines for errors in d3/win
David,
You will only want that file there when you are checking for errors. You should probably delete it otherwise or have a process that on a regular basis clears the file. It can cause systems to become slow for "no apparent reason" and often the file is forgotten and thus fills up with data well beyond its allocated size.
Dick
To post to this group, send email to designbais-forum@googlegroups.com.
To unsubscribe from this group, send email to designbais-forum+unsubscribe@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "DesignBais-Forum" group.
To post to this group, send email to designbais-forum@googlegroups.com.
To unsubscribe from this group, send email to designbais-forum+unsubscribe@googlegroups.com.
On Sunday, May 13, 2012 3:26:53 AM UTC+10, Bobby Worley wrote:
is the runtime-errors file a function of d3 or designbais? In other words, will it work for us users on AIX/Universe?Another debugging option is running DBI.RUN.LAST at tcl right after a browser failure, it has helped me in the past.
Sent: Saturday, May 12, 2012 12:13 PM
Subject: Re: Monitoring subroutines for errors in d3/win
David,
You will only want that file there when you are checking for errors. You should probably delete it otherwise or have a process that on a regular basis clears the file. It can cause systems to become slow for "no apparent reason" and often the file is forgotten and thus fills up with data well beyond its allocated size.
Dick
To post to this group, send email to designbais-forum@googlegroups.com.
To unsubscribe from this group, send email to designbais-forum+unsubscribe@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "DesignBais-Forum" group.
To post to this group, send email to designbais-forum@googlegroups.com.
To unsubscribe from this group, send email to designbais-forum+unsubscribe@googlegroups.com.
On Sunday, May 13, 2012 3:26:53 AM UTC+10, Bobby Worley wrote:
is the runtime-errors file a function of d3 or designbais? In other words, will it work for us users on AIX/Universe?Another debugging option is running DBI.RUN.LAST at tcl right after a browser failure, it has helped me in the past.
Sent: Saturday, May 12, 2012 12:13 PM
Subject: Re: Monitoring subroutines for errors in d3/win
David,
You will only want that file there when you are checking for errors. You should probably delete it otherwise or have a process that on a regular basis clears the file. It can cause systems to become slow for "no apparent reason" and often the file is forgotten and thus fills up with data well beyond its allocated size.
Dick
To post to this group, send email to designbais-forum@googlegroups.com.
To unsubscribe from this group, send email to designbais-forum+unsubscribe@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "DesignBais-Forum" group.
To post to this group, send email to designbais-forum@googlegroups.com.
To unsubscribe from this group, send email to designbais-forum+unsubscribe@googlegroups.com.
On Sunday, May 13, 2012 3:26:53 AM UTC+10, Bobby Worley wrote:
is the runtime-errors file a function of d3 or designbais? In other words, will it work for us users on AIX/Universe?Another debugging option is running DBI.RUN.LAST at tcl right after a browser failure, it has helped me in the past.
Sent: Saturday, May 12, 2012 12:13 PM
Subject: Re: Monitoring subroutines for errors in d3/win
David,
You will only want that file there when you are checking for errors. You should probably delete it otherwise or have a process that on a regular basis clears the file. It can cause systems to become slow for "no apparent reason" and often the file is forgotten and thus fills up with data well beyond its allocated size.
Dick
To post to this group, send email to designbais-forum@googlegroups.com.
To unsubscribe from this group, send email to designbais-forum+unsubscribe@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "DesignBais-Forum" group.
To post to this group, send email to designbais-forum@googlegroups.com.
To unsubscribe from this group, send email to designbais-forum+unsubscribe@googlegroups.com.
On Sunday, May 13, 2012 3:26:53 AM UTC+10, Bobby Worley wrote:
is the runtime-errors file a function of d3 or designbais? In other words, will it work for us users on AIX/Universe?Another debugging option is running DBI.RUN.LAST at tcl right after a browser failure, it has helped me in the past.
Sent: Saturday, May 12, 2012 12:13 PM
Subject: Re: Monitoring subroutines for errors in d3/win
David,
You will only want that file there when you are checking for errors. You should probably delete it otherwise or have a process that on a regular basis clears the file. It can cause systems to become slow for "no apparent reason" and often the file is forgotten and thus fills up with data well beyond its allocated size.
Dick
To post to this group, send email to designbais-forum@googlegroups.com.
To unsubscribe from this group, send email to designbais-forum+unsubscribe@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "DesignBais-Forum" group.
To post to this group, send email to designbais-forum@googlegroups.com.
To unsubscribe from this group, send email to designbais-forum+unsubscribe@googlegroups.com.
Tony Gravagno
That's a D3 thing. David asked specifically about D3. I believe Universe has something similar, I don't recall at the moment.
T
Bobby Worley
From: Tony Gravagno <ex2v...@sneakemail.com>
To: designba...@googlegroups.com
Sent: Monday, May 14, 2012 1:47 PM
Subject: RE: Monitoring subroutines for errors in d3/win
Tony Gravagno
Umm, how to respond to that? :)
You're certainly not alone. There are a lot of people dedicated to DesignBais out there. I'm not working with DB now so I rarely participate here anymore. But I've been a big fan of the software since I first saw v3. I think the software does great things and has potential to do even more. I miss working with it. I wrote a bunch of blog entries some years ago, and was writing a book on the software, but alas that didn't work out. I don't have DB installed to do any more follow-ups or new material, but you are welcome to peruse my blog and ask questions here about what you see, and maybe someone will answer. Have fun!
T