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

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

3431.0. "Handler to "handle" fatal IO errors?" by AIDA::CARCANO (Matteo Carcano, Italian ACT Milan) Thu Oct 04 1990 15:18

    What my customer needs to do is keep the client application alive even
    if one of the servers it is connected to causes the single connection to 
    be aborted giving origin to a fatal X IO error. 
    Reading the manuals and the notes about this problem, I understand that
    there is not a "pure X" solution to the problem. 
    He's not worried about portability, though. 
    So, what I'm looking for is an example or at least some suggestions on how 
    to "fix" this problem when writing a DECwindows/VMS application.
    
    Thanks a lot,
    
    Matteo 
    
    (cross-posted in decwindows_programming)

T.R	Title	User	Personal Name	Date	Lines
3431.1		DECWIN::FISHER	I like my species the way it is" "A narrow view...	`Wed Oct 10 1990 20:35`	5
	I fear there is no good solution to this problem. The bad solution is to spawn a subprocess to do all the DW work, let it die if the connection dies, and then spawn another one. Burns
3431.2	Bad news...	AIDA::CARCANO	Matteo Carcano, Italian ACT Milan	`Thu Oct 11 1990 10:35`	23
	Thanks for the reply, anyway. Unfortunately this solution cannot be applied by the customers. He has a single client process opening N displays on N different VT1000. Once a single VT1000 is turned off he wants the other N-1 VT1000s to keep working independently of the single connection aborted. I know that a "pure X" solution doesn't exist. The first thing that comes in mind is to re-design the application having a 1-1 correspondance between a client process and a single server. But it's probably too late... Does anyone know how (if it can be done) to trap the "timeout expired" message that the LAT transport layer passes up to Xlib? (this is how I imagine that the session aborted message is generated). Is there any way for the "host" system to know that a VT1000 connected to it has been turned off? Is ther any documentation around on the LAT transport layer attached by Xlib when the server is a VT1000? Any ideas, suggestions, or examples are very very welcome. Thanks a lot, Matteo
3431.3	Possible in the not to distant future?	IO::MCCARTNEY	James T. McCartney III - DTN 381-2244 ZK02-2/N24	`Thu Oct 11 1990 16:21`	8
	Is the DXSetIOErrorMode() call still going into DECWindows? If so that would at least provide a DEC solution... Thanks James
3431.4		STAR::HARDY		`Fri Oct 12 1990 20:28`	10
	>Is the DXSetIOErrorMode() call still going into DECWindows? Yes. This provides a limited capability to continue if an application loses one of its connections. It does not help applications which have only one connection and wish to continue. You'll need DW V3 to try it. DW V3 should be going to internal field test in the near future. Sam
3431.5	A brief description?	ORTICA::CARCANO		`Tue Oct 16 1990 08:10`	6
	Could you please give a brief and "unofficial" description of the DXSetIOErrorMode() routine? Thanks, Matteo