× 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.


  • Subject: Re: Cleanup after program failure
  • From: Matthias Oertli <oertlim@xxxxxxxxxxxxxxxx>
  • Date: Sat, 05 May 2001 01:02:20 +1000
  • Organization: Habba doo daa...

Hi,
Thanks for all the suggestions.
Because I only have no control over program B, I decided to start it
in a group job. Program A puts parameters into the *GDA. I wrote a
small CL as the initial program on a TFRGRPJOB that retrieves the
parameters from the *GDA, modifies the environment and calls program B
appropriately. Now even if there are problems with program B (which I
don't care about), the worst that can happen is that the group job
terminates. Program A still has the proper environment.

This raises one further question though: Is it possible to read/write
the *GDA from a RPG program (using IN/OUT)? It works for the *LDA but
I can't figure it out for the *GDA.

Thanks for all the replies.
Best regards,
Matthias

Buck Calabro wrote:
> 
> 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

-- 

---------------------------------------------------------------------
Matthias Oertli   <oertlim@s054.aone.net.au>
+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.