Re: Exit point programs

["Steve Moland" <steve@xxxxxxxxxxx>]

That was a concern when we designed in the exit point programs in our 
software and it is a good thing to have on a checklist regardless.

The exit point programs in our stuff are called by our code and must be 
there for anything to run. Their existance is not optional. In fact they are 
all called and left running in the first cycle area of the main program. 
That way a problem is right there in your face rather than waiting for a 
possible program call that might not be done for days or even weeks on the 
more obscure exit points.

As supplied the exit point programs do nothing but return to the calling 
program. The source we provide has comments about "put such and such HERE" 
and they have all or most of the internal memory structures which are passed 
as parms. That way we don't have too many times where the data or flags or 
whatever that the customers programmer might want, is not available. BUT 
that is a two edged sword because it exposes stuff that if changed wrongly 
it could mess up code that the customer does not get source code to.

We solved that by having the name of the exit programs be variables in a 
system setting. That way we can put an "'as delivered" copy in place to 
prove that "yes we hear that you didn't do anything which should mess up our 
stuff, but isn't it odd that it only fails when your copy is running."

We encourage the customer's copy of exit programs to be stored in our 
software library and not a library in the customer's library list. That way 
it's a simple save and restore to have the proper stuff at an HA facility. 
Some don't of course follow our recommendation and stuff has failed at HA 
sites but luckily only during testing there.

Steve

> So, does anyone have a good checklist of obscure little ditties like this
> they have to catch in a HA environment?  Like, if I add an exit point
> program on the source system, make sure I get it on the target system.
> System values and so forth...  Or do all HA vendors just catch this?
>
> This discussion opened up my eyes to some stuff that I've missed in our HA
> environment.
>
> Rob Berendt
> -- 
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
>
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
> list
> To post a message email: 
> MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.