[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

2893.0. "<DOWN> in Index aborts Index form" by UTES09::EIJS (Simon Eijs @Utrecht; 838-2558) Mon Jun 21 1993 17:49

    
    Hi,
    
    A quick question.
    
    Situation: ALL-IN-1 V2.4 English. Patch 601, 602 and 603.
    
    A normal Index form, no special processing. Using a VT340, after
    building the Index, and instead of using <NEXT PAGE>, <NEXT SCREEN>,
    the customer is holding <DOWN> continiously. The 'bell' for the buffer
    overflow is there allright. Now, at a particular point the user is put
    back in the form from which the Index was called (this is an ARG form,
    not a MENU form). The first error message:
    
    	Error processing form SEM$MAIL$INDEX
    
    And also an FDV message appears (unfortunately I cannot recall the
    exact contents of the message). 
    
    My question is if someone ever saw this happen, or better, if this
    might be a problem with FMS?
    
    Regrads,
    
    	Simon

T.R Title User Personal
Name Date Lines

2893.1 Data overrun error IOSG::CHINNICK gone walkabout Tue Jun 22 1993 10:31 21

T.R	Title	User	Personal Name	Date	Lines
2893.1	Data overrun error	IOSG::CHINNICK	gone walkabout	`Tue Jun 22 1993 10:31`	21
	Simon, I doubt that this is a problem but rather I think it's expected behaviour. When you fill the typeahead buffer the system sends either BEL or XOFF depending upon your terminal settings. If you keep sending data and the buffer overflows with some characters being lost then the system returns SS$_DATAOVERUN status to indicate that data is lost. From memory, FMS will return this as an error status to ALL-IN-1. If you want to stop this then either: - change the terminal characteristics to /HOSTSYNC which should force keyboard lock when the buffer fills - re-educate the users to not fill the buffer - set a larger typeahead buffer - possibly even set /ALTYPEAHD So - no problem with FMS - it's doing what it ought to. Paul.

    Simon,
    
    I doubt that this is a problem but rather I think it's expected
    behaviour.
    
    When you fill the typeahead buffer the system sends either BEL or XOFF
    depending upon your terminal settings. If you keep sending data and the
    buffer overflows with some characters being lost then the system
    returns SS$_DATAOVERUN status to indicate that data is lost. From
    memory, FMS will return this as an error status to ALL-IN-1.
    
    If you want to stop this then either:
    
    	- change the terminal characteristics to /HOSTSYNC which should
    	  force keyboard lock when the buffer fills
	- re-educate the users to not fill the buffer
    	- set a larger typeahead buffer - possibly even set /ALTYPEAHD
    
    So - no problem with FMS - it's doing what it ought to.
    
    Paul.