RE: Cleanup after program failure

In ILE programming, there is a wonderful technique called a condition.  I
wrote an article for MC on this for the March, 2001, edition.  A condition
is sort of an abstract error (because you can signal a condition yourself in
normal processing).  You can set a condition handler, and any condition will
then be passed to this handler.  That is, if an error occurs, this little
chunk of code will be called.  It's perfect for what you're talking about,
which is setting the state of the environment.

Proper use of conditions takes a bit of forethought - it's a little tricky
to try and anticipate what exactly is the right thing to do in different
circumstances - but used judiciously, you would certainly be able to avoid
the situation you describe.

I do have one question, though... why isn't program A checking for an error
and exiting appropriately?  If you do the error checking that Buck
describes, you'll be able to control your environment.  And, actually, the
default state on the AS/400 is to terminate the job step, so the fact that
you aren't means somebody actually specifically coded for the program to
ignore an error.

If I'm misunderstanding the situation, please let me know.

Joe




> -----Original Message-----
> From: owner-midrange-l@midrange.com
> [mailto:owner-midrange-l@midrange.com]On Behalf Of Buck Calabro
> Sent: Wednesday, May 02, 2001 8:38 AM
> To: MIDRANGE-L@midrange.com
> Subject: RE: Cleanup after program failure
>
>
> Matthias Oertli wrote:
>
> >I've been asked to code a call to program B from within program A.
> -snip-
> >My problem is this: If program B (or the CL) fails for whatever
> >reason, program A regains control without the environment having been
> >restored to what it should be which could mean disaster.
> >
> >How can I guard against this situation?
>
> I would write the cleanup functions as a separate
> program/procedure; ideally
> I'd include the "set up" and "remove" functions in one procedure
> and call it
> with a parameter that tells it which to do.  That way all your environment
> manipulation is done in one place.
>
> Once you have that, have A call B and have B pass back a "success/fail"
> flag.  Use whatever error trapping you need in B.  If B fails
> completely, A
> can still check the return code.  If it is not set for "success"  have A
> call the environment restore procedure.  If B completes, have it call the
> environment restore procedure.
>
> If you will be needing to do a lot of this, I would make a small
> change and
> write an "environment save" procedure and an "environment restore"
> procedure.  A does the save, B does the set, A does the restore.
> That way A
> is responsible for its own environment...
>
> I hope these ideas get you started in a direction that will work for you!
>
> Buck Calabro
> Commsoft; Albany, NY
> "Nothing is so firmly believed as
>  that which we least know" -- Michel Montaigne
> Visit the Midrange archives at http://www.midrange.com
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---