Conference vaxaxp::vmsnotes

482.0. "direct I/O and global sections" by UTOPIE::BRAUN_R () Wed Apr 16 1997 02:39

Hi all,

my customer (a large software partner) has a problem with direct I/O and
global sections. With DECnet, everything is o.k., as there is buffered
I/O on the lower layers, but when they run the same application via X.25
(only with the necessary changes: other library, system-calls,..), they
run into problems due to usage of direct I/O in the lower layers of the 
X.25-product on AXP. From other notes-conferences I got some infos, that
this is expected behaviour due to some "unchangeable" design issues of
both VMS and the X.25-products (and of course no IPMT can ever change
that). So far, so bad..

But the customer would be satisfied, if there is some bypass available
in the application (changes):

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, and this is due to usage of direct
I/O by the underlying X.25-product!!

The "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."


--> customer has to use the global section in the way above and has to
    use the X.25-call for incoming request.


Is there any programming bypass available, any documentation pointer
how to solve this situation ?


Any help will be highly appreciated.

Thanks,
Ralph

*****************************************************************************

From the DECNET-OSI_FOR_VMS-conference:



          <<< HELP::USER0:[NOTES$LIBRARY]DECNET-OSI_FOR_VMS.NOTE;1 >>>
                          -< DECnet/OSI for OpenVMS >-
================================================================================
Note 3875.0                X.25 direct I/O and RWAST ?                 4 replies
UTOPIE::BRAUN_R                                      61 lines  18-FEB-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

================================================================================
Note 3875.1                X.25 direct I/O and RWAST ?                    1 of 4
RMULAC.DVO.DEC.COM::S_WATTUM "Scott Wattum - FTAM/V" 18 lines  18-FEB-1997 14:30
--------------------------------------------------------------------------------
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
================================================================================
Note 3875.2                X.25 direct I/O and RWAST ?                    2 of 4
UTOPIE::BRAUN_R                                       8 lines  19-FEB-1997 04:26
                             -< no common memory >-
--------------------------------------------------------------------------------
    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
================================================================================
Note 3875.3                X.25 direct I/O and RWAST ?                    3 of 4
RMULAC.DVO.DEC.COM::S_WATTUM "Scott Wattum - FTAM/V" 12 lines  19-FEB-1997 07:52
--------------------------------------------------------------------------------
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
================================================================================
Note 3875.4                X.25 direct I/O and RWAST ?                    4 of 4
UTOPIE::BRAUN_R                                       3 lines  19-FEB-1997 10:23
--------------------------------------------------------------------------------
    Thanks a lot, will squeeze the VMS guys.
    
    Ralph

    A rogue DMA transfer -- speaking from experience -- can really ruin
    one's whole day.  (Or your whole week, if it's your driver that is
    apparently responsible. :-)  These corruptions can be obvious, or
    these can be very subtle and can lurk unnoticed for minutes or hours,
    blowing out DCL or random component.

    Under normal circumstances, I would not expect an application to
    expect a shared section to be deleted until all "pending" work was
    completed.

    Before issuing the $deltva, I'd issue a $cancel on any I/O outstanding
    against the section.  (And obviously, hopefully, the X.25 driver(s)
    are coded to accept and process I/O cancellation requests...)

    You might want to consider using a lock (and a counter stored in a lock
    value block), or an interlocked (adawi?) counter (stored in the global
    section) to keep track of the number of pending operations, and to prevent
    any attempt to $deltva until the section is quiescent. 

    I'd also include a way to detect a pending delete, and to prevent any
    operations from being queued after the delete has been queued -- this
    would avoid cases where a continuous series of operations can effectively
    prevent the deletion...

    You may also want to "elect" a coordinating process, and have a single
    process responsible for the coordination of the deletion.

    (And I will obviously assume there's a good reason for the deletion...)

    re .0
    
    I assume that this is the same topic as 221.

    Thanks,
    I'll forward these infos to the customer, but will also check, if
    there are chances for the X.25-product to be changed (if this is
    really at least unclean driver programming).
    
    Regards,
    Ralph