| 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 |
I sure hope someone out there has tried this. For the past week now I'v
been trying to get the XON & XOFF ASTs for the pseudo terminal drivers
to work.
I've created the necessary PTYx and WSAx devices and transfer data
with no problem, except sometimes I get a SS$_DATAOVERUN error and
have to resend part of a message. We noticed during testing recently
that sometimes the last half of a meessag truncated (lost) because
of the dataoverun. We've tried all types of ways of getting around
this and are now getting somewhat desperate.
The ASTs described in the documentation about the pseudo drivers &
devices sounds great but so far we can't get it to work. As soon
as I que an AST for either XON or XOFF the AST fires immediately.
I assume these are repeating ASTs (the documeintaton doesn't say).
We've tried to have the ASST requeue itself but that just seems to put us
in an infinite loop.
If anybody has an example of how to set these up or can point me in
the right direction it would make my evenings a lot nicer!
Cheers,
Cody
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2210.1 | It works in DECterm... | HANNAH::MESSENGER | Bob Messenger | Mon Feb 05 1990 21:45 | 63 |
Here's how DECterm does it (according to your description this should result
in an infinite loop, but maybe you're doing something differently):
/*
* set_xoff_callback()
*
* This routine enables notification of xoff. Typically, such xoff notification
* would occur when typein buffer has become full.
*/
static void
set_xoff_callback( stm )
STREAM *stm;
{
IOSB iosb;
int status;
extern void p_xoff_ast();
status = sys$qiow(
0,stm->pty.chan,IO$_SETMODE,&iosb,0,0,p_xoff_ast,stm->isn,0,2,0,0);
if ( FAILED( status ) )
log_message( "can't set xoff ast, status is %x\n", status );
else if ( FAILED( iosb.status ) )
log_message( "can't set xoff ast, I/O status is %x\n",
iosb.status );
}
/*
* p_xoff_ast()
*
* Come here at ast level if xoff condition is received from pty.
* Queue up event to be handled at non-ast level.
*/
void
p_xoff_ast (isn)
ISN isn;
{
non_ast (pty_xoff, isn);
}
/*
* pty_xoff()
*
* At main non-ast level, process the xoff condition.
*
*/
static void
pty_xoff (isn)
ISN isn;
{
STREAM *stm = GetSTM (isn,"xoff");
int count;
if (stm == NULL) return; /* only necessary because of bug in pty
/* driver that causes it to deliver ast
/* even after $cancel */
if (!stm->pty.active) return;
stm->pty.write_full = TRUE;
set_xoff_callback (stm);
}
| |||||
| 2210.2 | We must be doing something wrong! | SHALOT::FAILE | Thief! Baggins! We hates it! | Tue Feb 06 1990 08:39 | 28 |
Thanks for the reply Bob. Your note did shed some light on things;
however, now we get an invalid parameter everytime we try to set the
AST. Here's a sample of our code:
if ((status = SYS$QIOW (0, PTY_chan,
IO$_SETMODE, &iosb,
0, 0,
xoff_ast, offset,
0, 2, 0, 0)) != SS$_NORMAL)
db_stop(status);
The documentation sttes that the AST parameter can be a 16 bit
value and that the Xoff or Xon control character is written
back into the high order 16 bits. I'm assuming that this means
that the "offset" parameter I have above should be a longword with
the low-order 16 bits becoming the AST parameter and the high order
16 bits the indicaion of xon or xoff.
I've received the Invalid Parameter status with "offset" set to a
16 bit value, a longword value, and just 0. I noticed in your
sample code that you were using a pointer to a structure called
STREAM and that the parameter you passed to the p_xoff_ast was
stm->isn. Is there something here that we're missing?
Cheers,
Cody
| |||||
| 2210.3 | Suggest you use the new supported PT | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Wed Feb 07 1990 10:02 | 5 |
Note that in VMS V5.4, we are finally shipping a fully supported Pseudo-terminal driver. As DECwindows applications switch over to the supported one, you can expect the current TW/PY drivers to go away. Don't count on them! Burns | |||||