[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

624.0. "DECw Pseudo Device for DTM" by BOUDIN::GLOYD (Leslie Gloyd DTN:297-4615) Tue Apr 18 1989 14:56

    
 I get the message DTM-E-CLIENTTIMEOUT when attempting to record
 a test under DECwindows.

 My application runs both under DECwindows and on character cell
 terminals;  at run time it figures out which device to run on.  I
 use Jake VanNoy's method of determining the device type outlined in 
 "Specification for a Pseudo Workstation Device and Application 
 Output Device Selection in the DECwindows Environment." (June 8, 1988)
 
 I believe that the problem is that DTM changes the pseudo device, and 
 using the algorithm from above, it does not translate to a DECwindows device
 (Device class should be DC$_WORKSTATION and device type DT$_DECW_PSEUDO).
 Therefore, my application tries to exectute in character cell mode;
 hence the timeout error. At this point, I am unable to use DTM for testing 
 the DECwindows portion of my application.  

 Has anyone else run into a similar problem?  Is there a workaround?
 Is DTM planning to do anything about this in the next release?

 Thanks,                                                      

 Leslie

 This is posted in both the DTM and the DECWINDOWS notes files.

T.R Title User Personal
Name Date Lines

624.1 You are correct KOBAL::FULLERTON Fri Apr 21 1989 15:54 35

T.R	Title	User	Personal Name	Date	Lines
624.1	You are correct	KOBAL::FULLERTON		`Fri Apr 21 1989 15:54`	35
	<<< CLT::SYS$SYSDEVICE:[NOTES$LIBRARY]DTM.NOTE;1 >>> -< DEC/Test Manager >- ================================================================================ Note 730.1 DECw Pseudo Device for DTM 1 of 2 HARPY::FULLERTON 26 lines 19-APR-1989 11:43 -< You are correct >- -------------------------------------------------------------------------------- > I believe that the problem is that DTM changes the pseudo device, and > using the algorithm from above, it does not translate to a DECwindows device > (Device class should be DC$_WORKSTATION and device type DT$_DECW_PSEUDO). Your absolutely right on this. DTM redirects client connections to its intercept by redefining the DECW$DISPLAY logical to point to our intercept instead of the "real" Xserver. We are using the old method here of defining DECW$DISPLAY to be 0::1 to have X$OPEN_DISPLAY connect to our intercept. We have yet to implement creation of a new Pseudo-Device. All applications we were aware of, up to this point, were determining whether to bring up a DCL interface by first attempting X$OPEN_DISPLAY and upon failure to connect to assume that a character cell interface should be initiated. Therefore we had not set a high priority on implementing the Pseudo-device, especially since the QIOs for getting the information from the Pseudo-devices were not publically available. This is not to say the your approach is incorrect, it is. You may work around this problem by first determining if (1) the DECW$DISPLAY logical exists and (2) if it does determining if it points to a Pseudo-device and if not assume that it follows the old yet still supported method of defining the logical to be of the form <node>::<server>. DTM for V3.1 will be supporting a different record and playback methodology which does not require insertion of DTM between server and client. Therefore DTM will not be defining a DECW$DISPLAY logical when the new methodology is implemented. George

              <<< CLT::SYS$SYSDEVICE:[NOTES$LIBRARY]DTM.NOTE;1 >>>
                             -< DEC/Test Manager >-
================================================================================
Note 730.1                 DECw Pseudo Device for DTM                     1 of 2
HARPY::FULLERTON                                     26 lines  19-APR-1989 11:43
                              -< You are correct >-
--------------------------------------------------------------------------------
 
> I believe that the problem is that DTM changes the pseudo device, and 
> using the algorithm from above, it does not translate to a DECwindows device
> (Device class should be DC$_WORKSTATION and device type DT$_DECW_PSEUDO).

Your absolutely right on this.  DTM redirects client connections to its
intercept by redefining the DECW$DISPLAY logical to point to our intercept
instead of the "real" Xserver.  We are using the old method here of defining
DECW$DISPLAY to be 0::1 to have X$OPEN_DISPLAY connect to our intercept.
We have yet to implement creation of a new Pseudo-Device.  All applications
we were aware of, up to this point, were determining whether to bring up
a DCL interface by first attempting X$OPEN_DISPLAY and upon failure to connect
to assume that a character cell interface should be initiated.  Therefore we
had not set a high priority on implementing the Pseudo-device, especially since
the QIOs for getting the information from the Pseudo-devices were not
publically available.  This is not to say the your approach is incorrect, it is.
You may work around this problem by first determining if (1) the DECW$DISPLAY
logical exists and (2) if it does determining if it points to a Pseudo-device
and if not assume that it follows the old yet still supported method of
defining the logical to be of the form <node>::<server>.

DTM for V3.1 will be supporting a different record and playback methodology
which does not require insertion of DTM between server and client.  Therefore
DTM will not be defining a DECW$DISPLAY logical when the new methodology is
implemented.

George