Conference bulova::decw_jan-89_to_nov-90

Re: .0

One approach would be to obtain the window IDs of the terminal emulators
and use XSendEvent to send simulated user input to those windows (the terminal
emulator windows could be unmapped so the user wouldn't see them).  I think
this would be pretty clumsy, though: you'd have to make a lot of assumptions
about the exact pixel-level positioning of data within the windows.

It would probably be better to communicate to each application through a pseudo
terminal device instead of actual terminal emulators, so that your application
reads and writes to each application as if it were an IBM/DEC terminal.  You
could parse the data written by each application just enough to be able to
extract the part that needs to be passed to the next application in the chain.

There may even be software already available that does some of this work
for you.

				-- Bob

    Perhaps DTM would be able to help?  
    
                            August G. Reinig

I have considered both of these suggestions already.  The problem I have is
that the in-stream interception would have a lot of overhead in I/O handling.
DTM is worth looking at a bit closer, but I am not sure that the terminal
emulators would be happy writing to a pseudo-terminal through DECwindow
calls.  Also, I am looking at both VAX/VMS and ULTRIX and this makes things
a little more gamey.

Besides, the virtual screen I want to access is already composed and visible
and I should be able to map to the window and suck the text off the screen
like a cut (no??).

+------------+	+----------------+  +----------------+
! IBM Window !  ! DECterm Window !  ! DECterm Window !
! <xxxx>     !  !  <______>      !  !		     !
!	     !  !     <yyyyy>    !  !    <_____>     !
--------------  ------------------  -----------------
  !                  ^  !                 ^
  !                  !  !                 !
  --- cut x -- paste--  --- cut y -- paste-


  I'd like to do this using just DECwindows capabilities without the local
or remote applications seeing anything unusual (except user efficiency).

  What'd'ya think?

Regards

Frank

Re: .3

>The problem I have is
>that the in-stream interception would have a lot of overhead in I/O handling.

The overhead would be less than the overhead of the terminal emulator reading
the data *and* displaying it on the workstation (even if it were to an
invisible window), not to mention the cost of cutting/pasting the data.

>DTM is worth looking at a bit closer, but I am not sure that the terminal
>emulators would be happy writing to a pseudo-terminal through DECwindow
>calls.

I think there is a version of DTM that simulates a DECwindows server, so that
it would be transparent to the terminal emulator.

>  Also, I am looking at both VAX/VMS and ULTRIX and this makes things
>a little more gamey.

That could be a problem.

				-- Bob

    re:            <<< Note 1567.4 by HANNAH::MESSENGER "Bob Messenger" >>>
    
> I think there is a version of DTM that simulates a DECwindows server, so that
> it would be transparent to the terminal emulator.
    
    In V3.1, DTM's moved *away* from the more or less unworkable DECwindows
    in-memory server to a much more plausible XTrap solution (a DECwindows
    extension which allows a "standard" simulation of input events and
    trapping of output requests in the context of the server).  I wouldn't
    look toward DTM for providing an in-memory server; however, we have
    submitted this as a phase 0 requirement for DECwindows V3 for future
    "batch" testing functionality.
    
    re: .0, .2
    
    Problem Clarification:
    Do these emulators support the DECwindows clipboard?  Namely, are you
    just looking for a method of *automatically* performing something that
    can be performed manually?  If so, I'd say DTM should be able to help
    you out with it's record/playback functionality and it's primitive
    scripting available with V3.1.
    
    However, if you're looking to have DTM initiate Xlib level inter-client
    communication, I'd have to say that DTM currently is in no way that
    extensible.
    
    Further information on DTM can be found in the CLT::DTM Notes File or
    by contacting the project leader George (harpy::) Fullerton.
    
    Regards,
    
    	 	== ken miller ==
    		(DTM Development)

OK,

  Let me restate the problem.  There are terminal emulators running into
three environments: IBM, DEC and Bull (through a VT100 emulator black box).
The IBM emulator is the DECwindows SNA Term and the others are DECterm.

Data entered into one window passes through to the host system and the results
come back to the screen.  Those results are then cut from the screen to be
used as input to one of the other terminal sessions on another host system.
Today, the user has three or more terminals on his desk along with a big
notepad.  He jots the reults down and then enteres the info via another 
terminal (a very tedious mechanical process easily handled by a computer).

  I am proposing running all the terminals in a worksystem and developing a
library of scripts to automatically do the same thing.  The user can then
interactively work in a window until he has arrived at a screen suitable
to be a starting point for one of these 'scripts'.  Click, he picks the
script that he wants to execute and viola the worksystem magically does
all of the tranferring from the IBM window to the DECwindow, waits for the
results, does another cut and pastes to yet another window, etc.  After
the script completes or detects an error (expected response does not occur
in the window), the user is either presented with a composite display with
the collected items displayed, or is focused to a screen where the unexpected
results were encountered.

  Meanwhile a table of results from the script is composed for applications
on the worksystem to manipulate:

Session:	IBM	Screen 16	NAME = 'Fred Smith'
					ADDRESS = '16 Cherrywood Lane'
					TELEPHONE = '202-555-1543'
					CUSTOMER_NO = '1976'

		Bull	Screen 47	CUSTOMER_NO = '1976'
					ORDER_1 = 'CP-1612'
					PO_1 = 'FS76
					ORDER_2 = 'FD-19227'
					PO_2 = 'FS99'

		DEC	Screen 9	DEC_ORDER = 'CP-1612'
					STATUS = 'Shipped'
					CARRIER = 'Federal Express'
					SHIP_DATE = '15-OCT-1989'

		DEC	Screen 9	DEC_ORDER = 'FD-19227'
					STATUS = 'In progress'
					CARRIER = ''
					SHIP_DATE = '30-OCT-1989'

  Here we have an example of a session to determine when Fred Smith's orders
will arrive.  The IBM system can tell us Fred's customer number, with that,
we can go into the Bull system and find out the order numbers that Fred
has currently in progress.  Then into the DEC system to find the status of
the orders.

  I know that this can all be applications programmed, but this way I give the
customer what he wants and he makes no changes to his applications or process.
Each known screen template is defined and mapped so the locations of each
field is defined and that the screen is identified somehow.  Now, all I have
to do is wait for the screen to be presented, look to see if it is the right
screen, select the info from the screen into a memory map and then move the
fields into place in an outbound screen.  repeat as necessary until an error
or the end of the script.

  Basically, a windows robot!

  My guess is that I have to develop a script application, but I need to solve
a few problems, such as cutting and pasting and also how to wait until the 
screen response from the host is ready to be looked at.  I have read through
DTM and feel that there is not enough there to handle this the way I need to.
A seudo-term/window means I have to do a lot of pass-thru when I am not
scripting and that puts a lot more overhead on the system.

  I hope that what I am trying to do is a little more clearly defined.  What
do you think?  Can it be done?  How?

  Any help would be appreciated.  I am running out of time and SUN has a
proposal on the table which is being considered, but it appears to be a
manual cut and paste.  To automate this would be a significant advantage.

regards,

Frank

Let me see if I can help here.  We seem to have been talking about three
flavours of DTM testing all in the same breath.

(1) First there is DTM terminal based recording and playback that utilizes
the pseudo-terminal capabilities of DTM to capture and replay data as it
passes between the "real" terminal and the application.  I don't beleive
use of this is feasible for doing what you want, especially since the IBM
terminal emulator is not currently supported, besides the additional
overhead.  I think the initiator of this note had figured this out anyway.

(2) Second, there was the DTM V3.0 DECwindows methodology that captured
and attempted to replay X-protocol with DTM masking itself as an X-server.
Use of this V3.0 capability for this purpose does not seem like a good
idea.

(3) Third, there are the new DTM V3.1 DECwindows testing capabilities that
utilized the XTrap XServer extension.  I think these capabilities might
be manipulated to suit your needs.  In DTM V3.1, DTM can now record DECwindows
mouse and keystrikes/keyreleases into a Session file.  Once recorded, DTM
through the Xtrap extension can replay the mouse and keystrikes/keyreleases
to the XServer in "real-time".  The XServer has no knowledge of the fact
that the mouse and keyboard input comes from XTrap and not from the "real"
devices.   Therefore, with DTM it is possible to record a session that
selects items from one terminal emulator and pastes them to another.
By replaying the recorded session over and over, one can then cut and
paste information over and over as one wishes.  Basically, a windows robot!

The cheif consideration with using such a replay to accomplish automated
cut and paste is whether the IBM terminal emulator you mention supports
global select or cut to clipboards, etc.  If it does I think that you should
be able to use DTM.

Please feal free to give me a call if you want more info.

Regards,

George Fullerton,
DEC/Test Manager Project Leader
( CLT::FULLERTON )

    Well, just to throw a little more fat into the fire here... :-)
    
    It sounds like you have a problem that is larger than you think.
    I don't believe that you can just write some application code to
    provided the capability that you're attempting to get. At least
    not in any sort of time-efficient way. You need some help from
    something like an X server extension such as Xtrap (like DTM is
    using.)
    
    I agree that you probably do need an application program, in
    addition to the server extension, in order to get just the
    functionality that you want. I suspect that the amount of
    control that you really want falls outside of the range of
    completely predictable actions and responses that are DTM's
    forte. (Sorry George, but regression testing doesn't suit
    everyone's needs.)
    
    If you're interested in pursuing this further I'm the keeper of
    the source code for Xtrap and can provide more detailed
    information about how to use it, how to write code to work
    with it, etc. While I can't solve your problem for you I do
    believe that this will put you a lot closer to a solution than
    you are right now, and with a lot less coding work.
    
    Xtrap works on both VMS and ULTRIX, for those of you who want
    to know.
    
    Dan

Dan,

  It sounds like we are on the same wavelength.  I think that DTM is a fine
product when you have a very predictable cause & effect environment, but
in cases where some "if .. then ..else" comes into play, it would depart
from DTM's main purpose - testing.  I think that the wizardry behind DTM
is wonderful and would help out a great deal, but can I bend it to do what
I need to do without breaking anything?

  Tell me a bit more about Xtrap.  I don't profess to be an X-pert, I will
get one in when required, but perhaps you can describe what Xtrap does and
how it can be used to help me solve my problem.  From the name, I can already
form an idea but I'd best wait to hear your answer.

regards

Frank

    Hi Folks!
    
    	Just thought I'd throw in my 2 pfennigs worth....
    
    	How about trying to get away from pixel/character grabbing
    	and trying to move up a layer? I seem to remember from my
    	SNA days that the IBM 3270 protocol splits everything up
    	into fields and cleanly (if that is a good word to use with IBM!)
    	splits up templates and their content. There is also a product
    	called "3270 data stream API" or something like that (help Dave!)
    	with which you could get your hands on the 3270 data stream.
    	Also on the DEC side, I assume that the applications are still to
    	be written for the VAX side, so maybe use something more structured
    	like DECforms. Then maybe you could do something like writing code
    	that matches field names from the IBM side with the DECforms field
    	names.
    
    	Just some idle ramblings to try and give you some ideas.....
    
    	Oh, as an aside, I heard that NewWave from HP has something called
    	a "Desktop Robot" which seems to record Toolkit (not Xlib) events
    	for later replaying. Neat idea, but not too helpful here!
    
    Regards,
    Paul Tallett,
    CEC Karlsruhe
    West Germany