filepro menus and Ctrl-S - maybe Anzio setting?

[Bruce Easton]

On 12/9/10 11:01 AM, George Simon wrote:
>>> If I understand your clarification, it is NOT that the user is typing
>>> ctrl-S, it's that a menu file that happens to SHOW a ctrl-S (if you open
>>> it in an editor, which is not recommended) somehow causes a problem.
>>> Right?>>
>>> If that is true, and IF filePro somehow displayed (output) that ctrl-S,
>>> then it is possible that this causes a problem with Anzio (and not with
>>> PuTTY).
>>>
>>> Regards,
>>> ....Bob Rasmussen,   President,   Rasmussen Software, Inc.
>> (I'm assuming the top post below was later than what was on the bottom;
>> I don't think that reply from Bob every made it to me.  Anyway - it
>> looks like the exact behavior is answered in the top post below.)
>> Have you tried making a new menu on the Linux box with 19 options on it
>> and calling it from another menu?  Also, could there be something on the
>> calling menu option that is changing the environment in some way before
>> referencing the target menu?
>> Bruce
>
> There is nothing in the calling menu that changes the environment.
> This just doesn't happen to 1 menu with 19 lines, it happens to several menus with 19 lines and they are all called from different user menus.  To be honest, we have so many menus that I could not even tell you if it happens to all 19-line menus that we have because I have not checked them all but that would be my guess.
>
> This problem came to light when we had the users testing the system using the new Linux server.
> They reported the problem and when we checked it, we couldn't figure out what was happening until Cesar (who did the transfer from the SCO Unix server to the new Linux server) discovered that all the menus we were having problems with all had 19 lines and that adding one line to the menu solved the problem.  So it must be the ctrl-S that is triggering Anzio locking of the keyboard.  The question is, why is it only when called from another user menu and not from the command line or dpromenu.
>
> Here are some more findings:
>
> 1 - If I write a new 19-line menu from scratch, identical to the menu that locks up but with the menu option titles only and without any commands, the menu does not lock up when executed from the command line, dpromenu or another user menu.
>
> 2 - If I add the identical commands to the new 19-line menu, the menu does not lock up when called from the command line, dpromenu or another user menu.
>
> 3 - If I try to look at the new 19-line menu using more, more locks up.  Perhaps I should say Anzio locks the keyboard.
>
> 4 - If I try to look at the new 19-line menu using less, Anzio does not lock the keyboard.
>
> 5 - If I open the 19-line menu file with vim, Anzio does not lock the keyboard.
>
> So at this point, since more also locks up the keyboard, I guess we can eliminate filePro as being the culprit from the equation. It has to be the ctrl-s in Linux triggering some action in Anzio that makes it lock the keyboard up in some instances. Why doesn't filePro lock up if you write the 19-line menu in the Linux box is anyone's guess.
> Obviously the problem still exists, as Anzio locks up the keyboard if more is used to read the file.
>
>
> George Simon
> American River International

George, is your Anzio set up to ssh to that Linux box using SCO Unix as 
the declared terminal type?  I seem to remember that your Anzio might be 
set up that way.  If so, could you try to set it to linux or xterm and 
see if you still get the same behavior?

Bruce
Bruce Easton, STN, Inc.