Re: Understanding Engine program glitch

[Jack Woehr <jwoehr@xxxxxxxxxxxxxxxxxxxxxxxx>]

Your narration sounds like a simple concurrency problem.

   - Processes served by multiple independent entities.
   - Entities synchronized on collection of library objects which may
   independently change.
   - Unplanned switchover in mid-transaction between lost old objects and
   new objects before processing queues drained.

The old transactions complete with the new code which itself is sheltering
incompatibiities.

Or "boom!" for short.

On Wed, Jun 19, 2019 at 1:27 PM Vinay Gavankar <vinaygav@xxxxxxxxx> wrote:

> Hi,
>
> I am trying to find an explanation for a glitch that occurred in our
> processing, and hoping someone here can help.
>
> We have multiple engines running 24x7 to process transactions. The main
> program reads the transaction from a data queue and then calls multiple
> programs, each doing multiple validations to process the transaction. None
> of the programs in the call stack close down until the engine is closed
> down.
>
> Normally, when there is a change to one of the programs, the old program
> object is moved from production library to a temporary library which is at
> the end of the library list of the engine job. The changed program object
> is then installed to the production library, and the engines are shut down
> and re-started ('recycled') one at a time, so as not to interrupt
> transaction processing.
>
> During the last install when a program (PGMA) in the stack was being
> changed, the step to move the object to temporary library was missed, due
> to which the old object (which was being used by the engines) was deleted
> and new object was installed in production library.
>
> The step to 'recycle' the engines was done about 20 minutes later.
>
> All the transactions processed within that 20 minute window were rejected
> due to a validation in PGMA. It was as if one of the fields (passed as a
> parameter) which should have a zero value, had a non-zero value.
> The changes to PGMA did not involve a change to the incoming parameters.
>
> All transactions processed after the 'recycling' of engines were fine, and
> also when the rejected transactions were submitted again later, they
> processed successfully without any error.
>
> Is it possible that this happened due to the destruction of the object in
> the call stack?
>
> I know it was a long-winded story, but any help will be greatly
> appreciated.
>
> Vinay
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxx for any subscription related
> questions.
>
> Help support midrange.com by shopping at amazon.com with our affiliate
> link: https://amazon.midrange.com