Re: Debugging

Steve Richter wrote:

I would like to see the entire call stack preserved, all the static
and automatic storage, all the open data paths. On the database side,
with complete journaling, I would like to tell the system I want to
resume a job with the database set to the state it was at on the date
and time the job failed.

I was looking at the situation from a problem determination / debugging front. This sounds like the recovery part.

When you ask for the call stack and storage to be preserved, do you mean in such a way that you can change recompile the program and pick up exactly where you left off, or are you thinking more of documentation to discover where the problem is? If the latter, various dumps do that today. If the former, I can't see how to restart an HLL program at the same instruction after the program has been recompiled and the instructions no longer match the preserved (halted) job.

For setting the database back to the state it was at at the point of an error, if your application doesn't COMMIT and ROLLBACK on its own, have a look at RMV and APYJRNCHG, available at least since S/38 CPF release 8. In general I would find it difficult to resume a job (apparently a batch job) by rolling the database backward because I would be losing changes made while I was working on the program. But I understand that there are still places where pure batch processing occurs (e.g. nightly jobs with no interactive users on.)

This borders on application design rather than debugging, but it's a pet peeve of mine that so few programmers trap I/O errors. I'm in the camp that feels a robust program expects errors and is ready to handle them. In the case of a batch transaction process, the input file has a 'processed' flag that gets COMMITted during the same commit cycle that the master file gets updated. Then a restart is as simple as running the job again. The records that were updated are skipped on the rerun because they are already tagged, and the record that was partially updated during the error was rolled back and so never updated at all.

Just like the Agile people like to make code that's inherently testable, I think that our code should be inherently re-runnable.
--buck