× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



From: Walden H. Leverich

How does the joblog help you debug a
missing customer? Not the entire table, just a missing row... You know,
debugging those inevitable "the row must be here... but it's not..."
errors? Or help you deal with errors in logic in computing the price of
an item? Or it's shipping weight, etc.?

First, these ARE system level errors. You have some bad data if you're
missing customers, and if you are using a log to debug logic errors, you
don't deserve to be coding.

But beyond that, this is where the feature I mentioned in my previous email,
the ability to go in and start a debug session on a running job, is so
powerful. If I program in simple assert logic to check for unexpected fatal
data conditions and I throw an error message to the system operator, the
programmer can go in and debug the program. This will work for interactive,
batch or even web applications. And with WDSC, I can even set a service
entry point on the assertion program and gain control directly into WDSC
automatically.

In fact, the only thing that you can't (or perhaps shouldn't is the better
term) handle this way is the infamous intermittent error, which probably
needs old-fashioned logging.


The joblog is great for system-level stuff. There's no argument there.
But I'd guess most "bugs" aren't system-level issues.

Ah, that's Windows programming vs. midrange programming. The way I learned
to program, you actually tested your code before it got into production,
including end points. You know, all that old rigamarole about having test
plans and unit tests and integration tests, which is now pooh-poohed by the
extreme programming crowd <chuckle>.

That stuff made sure that the programmer found all but the most severe
data-derived errors in programming, and then put hard halts in place for
even the data errors. Yes, occasionally bad data gets in (especially when
you allow ODBC updates to your data) but even then your program should
either alert the system operator, or in those cases where you must continue
processing, then indeed it needs to log the problem.

If, on the other hand, you regularly have bugs getting into production, then
you have a serious problem in your development environment. And the idea
that bugs in production code are to be expected, and even tolerated, is
perhaps the single most destructive thing Microsoft has done to the IT
industry.

Not that I have an opinion on the issue or anything <grin>.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.