Conference ozrock::x25_avms

499.0. "X.25 direct I/O and RWAST ?" by UTOPIE::BRAUN_R () Wed Feb 19 1997 04:49

(cross-posted in DECNET-OSI_FOR_VMS, X25PSI and X25_AVMS)


Hi all,

sorry, if some of the following information is inaccurate, also showing
my shameful poor knowledge of VMS programming:


Our customer, a software partner company has the following problem with
X.25, buffered I/O and direct I/O:

VAX4000-60 + DECstation 2000-300, OpenVMS 6.2, DNOSI 6.3, ECO3    X.25 V1.0-E

(but the problem seems to be same on AXP)


application declares as X25 Destination
application accepts a connection (X25 Confirm)
application sets an asynch. Read-QIO to receive a new 
  packet within as AST-routine. 

application maps a global section 
application copies data to this section.
application tries to remove this section via $DELTVA from its address space.


--> $DELTVA-service is unable to finish, hangs forever: only 
    an incoming X.25-packet (thereby finishing the direct I/O)
    is interupting (and finishing) this hangup.


But this hangup only occurs, if the global section is shared 
by "many" processes at the same time.
If the global section is initialized and used by this test program only,
the problem will not occur.
If there is only one other test program initializing the section and the
application above is only accessing the section, the problem will not
occur, too. 


 - process is hanging in RWAST-state, how to find the reason via
   SDA (VMS-guy told me, this is very specific depending on the
   situation)
      (some pointer to SDA-sniffing required)


 - customer wants to know about the potential problem of direct
   I/O (X.25):  with DECnet (buffered I/O) instead of X.25
   the same application (X.25-calls changed to DECnet-calls)
   does not hang.

   According to the customer, the problem could be due to 
   direct I/Os  (??????) 


Any help will be highly appreciated.

Thanks,
Ralph

> --> $DELTVA-service is unable to finish, hangs forever: only 
>     an incoming X.25-packet (thereby finishing the direct I/O)
>     is interupting (and finishing) this hangup.
	Sounds as if the application has specified the X.25 
read buffer is within the global section. If that is so, and 
another process is using the global section then the global
section cannot be deleted from the address space (the read
effectively has locked it) until the read completes.

	Don't remove global sections from the process
address space if you are doing i/o into them unless the i/o
has completed. Makes sense to me!

Further to my previous reply, yes NWDRIVER uses direct i/o's for READs.
This will lock the buffer in the process working set.