Re: Understanding Engine program glitch

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