[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

1726.0. "FIleviews keep going away..." by COPPER::D_BERRY () Mon Nov 13 1989 10:12

Can someone tell me where there may be a log file for FILEVIEW? or if you might
know what the problem is...

I keep having FILEVIEWs go away when starting an application (such as DECwrite or
NOTES).  This behavior is very inconsistant in that some time later applications
will start with no problem...

I am using VMS 5.3 and DECwindows V2.0.

T.R Title User Personal
Name Date Lines

1726.1 A possible reason... LNKUGL::BOWMAN Bob Bowman, CSC/CS SPACE Team Mon Nov 13 1989 21:50 18

T.R	Title	User	Personal Name	Date	Lines
1726.1	A possible reason...	LNKUGL::BOWMAN	Bob Bowman, CSC/CS SPACE Team	`Mon Nov 13 1989 21:50`	18
	I suspect you have run into a problem which I QAR'd during field test. (I don't think it has been resolved yet.) Try selecting a file before doing any operation. If FILEVIEW does not abort as it has been doing, this may be the same issue. What I found appeared to be a bug in which if no selection had been made, or if it was "flushed" (letting FILEVIEW sit idle over a weekend appeared to make any previous selection "inactive"), then when a call was made to get a "selection" size chunk of memory, the size of the selection was returned as 0, and hence a 0 piece of virtual memory is requested, resulting in a fatal error. (You can see this by executing FILEVIEW from a DECTerm rather than from the Session Manager menu.) If Selections don't seem to have an effect on your issue, you'll need to look elsewhere. I recommend running FILEVIEW from a DECTerm in which a SET PROCESS/DUMP has been issued. This may leave a process dump file which might be usefull in analyzing the problem.

    I suspect you have run into a problem which I QAR'd during field test.
    (I don't think it has been resolved yet.)
    
    Try selecting a file before doing *any* operation. If FILEVIEW does not
    abort as it has been doing, this may be the same issue.
    
    What I found appeared to be a bug in which if no selection had been
    made, or if it was "flushed" (letting FILEVIEW sit idle over a weekend
    appeared to make any previous selection "inactive"), then when a call
    was made to get a "selection" size chunk of memory, the size of the
    selection was returned as 0, and hence a 0 piece of virtual memory is
    requested, resulting in a fatal error. (You can see this by executing
    FILEVIEW from a DECTerm rather than from the Session Manager menu.)
    
    If Selections don't seem to have an effect on your issue, you'll need
    to look elsewhere. I recommend running FILEVIEW from a DECTerm in which
    a SET PROCESS/DUMP has been issued. This may leave a process dump file
    which might be usefull in analyzing the problem.