[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference help::decnet-osi_for_vms

Title:DECnet/OSI for OpenVMS
Moderator:TUXEDO::FONSECA
Created:Thu Feb 21 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3990
Total number of notes:19027

3875.0. "X.25 direct I/O and RWAST ?" by UTOPIE::BRAUN_R () Tue Feb 18 1997 13:37

(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

T.RTitleUserPersonal
Name
DateLines
3875.1RMULAC.DVO.DEC.COM::S_WATTUMScott Wattum - FTAM/VT/OSAK EngineeringTue Feb 18 1997 14:3018
This would appear to be more of an OpenVMS question, wouldn't it?

In any event, my Internals and Data Structures manual seems to be pretty clear
on one point:  "If the process has direct I/O in progress, its I/O must complete
before this page can be deleted."

The text goes on to describe how the process will be put into RWAST and under
what circumstances (which appear to include the times when the page is mapped to
more than one process - which would plssibly explain what your customer is
seeing).

So, at an admittedly quick glance (and a not very good understanding of this
aspect of OpenVMS memory management), this looks like expected behavior that's
independant of X.25, but directly related to direct I/O.  I think if you need a
better answer, you should check an OpenVMS conference.

fwiw,
--Scott
3875.2no common memoryUTOPIE::BRAUN_RWed Feb 19 1997 04:268
    Scott,
    
    thanks a lot for your answer, but according to the customer, the global 
    section has nothing in common with the memory buffer being used for the 
    direct I/O.
    
    Thanks,
    Ralph
3875.3RMULAC.DVO.DEC.COM::S_WATTUMScott Wattum - FTAM/VT/OSAK EngineeringWed Feb 19 1997 07:5212
I don't think it matters.  The text in the VMS internals manual did not seem to
care whether the memory was directly related to an I/O transfer or not - I
suspect this may be because VMS cannot tell during the page deletion process
whether the page could potentially be involved in a direct I/O operation (as a
buffer, or what have you).

This is why I suggest an OpenVMS conference - you're going to find people that
really *know* memory management and can confirm for you whether this is expected
- my quick look at the internals manual suggests that this is normal.

fwiw,
--Scott
3875.4UTOPIE::BRAUN_RWed Feb 19 1997 10:233
    Thanks a lot, will squeeze the VMS guys.
    
    Ralph