Process bypass

[Kenneth Brody]

On 9/27/2012 4:44 PM, Rami Mantoura wrote:
> When in input it checks a status and the command is (chain "chscr1"). it
> leaves me in screen 1. I update the fields and hit esc esc. My old server
> would go to the top of chscr1 table. not it goes directly to auto. Nothing
> changed. All I did was move the complete file from one server to the other.
> It still works on the old server now.

You still haven't explained all the steps that goes on.

Break it down, step by step...

How is input processing started in the first place?

When does the CHAIN occur?

What happens in the chained processing?

What causes the person to enter update on a screen while in the chained process?

Are you 100% certain that you have identical processing on the old system 
and the new system?

Where, exactly, does processing go on the old "working" system, when the 
user presses SAVE while updating the screen from within the chained process?


Note that the only time processing implicitly starts at line 1 of the input 
table is when pressing SAVE on a screen when no processing was currently 
running.  Yet, you say you are already running processing when filePro 
somehow starts at line 1.


> On Thu, Sep 27, 2012 at 4:26 PM, Kenneth Brody <kenbrody at spamcop.net> wrote:
>
>> On 9/27/2012 3:26 PM, Rami Mantoura wrote:
>>
>>> Here is the sequence and keep in mind it does work on the SCO box
>>> currently
>>> so I am wondering if something changed.
>>> Auto process starts, then input processing, It does a chain command to a
>>> second process. (here is the problem) They fill in data and hit esc esc.
>>> (it should go to the top of the second process at that point.... Correct?)
>>> then back to auto and then input.
>>>
>> [...]
>>
>> How, exactly, does "then input processing" occur?  What causes input
>> processing to start?  Where does it do the CHAIN?  How does the chained-to
>> process enter update on a screen?

-- 
Kenneth Brody