[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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.R | Title | User | Personal Name | Date | Lines |
---|
3875.1 | | RMULAC.DVO.DEC.COM::S_WATTUM | Scott Wattum - FTAM/VT/OSAK Engineering | Tue Feb 18 1997 14:30 | 18 |
| 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.2 | no common memory | UTOPIE::BRAUN_R | | Wed Feb 19 1997 04:26 | 8 |
| 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.3 | | RMULAC.DVO.DEC.COM::S_WATTUM | Scott Wattum - FTAM/VT/OSAK Engineering | Wed Feb 19 1997 07:52 | 12 |
| 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.4 | | UTOPIE::BRAUN_R | | Wed Feb 19 1997 10:23 | 3 |
| Thanks a lot, will squeeze the VMS guys.
Ralph
|