[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | VAX C Notes |
| Notice: | READ 1.* BEFORE WRITING; USE KEYWORDS TO FIND EXISTING NOTES |
| Moderator: | DECC::VMCCUTCHEON |
|
| Created: | Sat Jan 25 1986 |
| Last Modified: | Mon Jun 02 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 5611 |
| Total number of notes: | 27963 |
5608.0. "Wierd open() Call Failure - Suggestions?" by DRAGNS::SAUNDERS (John Saunders, DECdns Engineering, (508) 275-5424) Thu May 08 1997 11:42
This question is part of the problem in 5604.*, especially 5604.10.
We have narrowed down this problem to the point where we're about to transfer it
to OpenVMS. The problem can now be described as follows:
Early in its initialisation, the DNS Advertiser enumerates the LAN devices on
the system and opens two ports on each device: one for 802E format, and one for
Ethernet format. Later in the initialization, it attempts to open a file in
SYS$SYSTEM: read-only:
versionfile = open(DNS_CACHE_VERSION, O_RDONLY, 0);
if (versionfile < 0) {
#if _DNS_OS_ == _DNS__VMS
TraceIf(M_TRACE_DNS,perror("CA_ReadCurrentVersion"););
#endif
return(-1);
}
This fails with a RMS$_ACC error. We don't know what the STV value is.
We have narrowed down this problem by using this open call as a diagnostic. It
turns out that if we do the open before the SYS$QIOW that opens the LAN port,
and do another one after it, the second open fails on the second port of the
fourth LAN device (an FDDI device in this case). Another customer had a similar
problem at the fifth LAN device, which was an Ethernet device in his case.
Now, that's almost certainly an OpenVMS LAN Drivers problem, and I'm probably
going to transfer this case today. In the meantime, I've got the only program
that can reproduce this problem.
I'm assuming this is some sort of data corruption problem caused by that last
$QIOW. The questions are:
1) Any guesses from RTL people as to what the LAN drivers could be trashing? We
get no other strangeness from the RTL, just from open().
2) Are there any quick diagnostics you can think of that I can add at the site
of the failure? LIB$VERIFY_VM_ZONE or something?
3) Any other guesses?
Thanks,
John Saunders
DECdns Engineering
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5608.1 | Get STV | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu May 08 1997 12:21 | 23 |
|
The STV value is the key here... Without that, we are guessing.
I'd display the STV value, and I'd tend to go directly to the RMS
sys$open() call, as there is far better control of the operations
via that call than via the VAX C (are you still really using the
VAX C compiler?) open() call.
I'd also check the process quotas -- as this sort of weirdness could
also result from insufficient process quotas.
I'd check the contents of the FAB and the RAB, and the variables
adjacent to the FILE pointers. Access to the FAB and the RAB is a
little tricky -- this is why I prefer direct RMS access -- but see
TURRIS::CC (VAX C) note 3887.1 for how to find these structures
"underneath" the VAX C RTL.
--
:This question is part of the problem in 5604.*, especially 5604.10.
Why a seperate note, then?
|
| 5608.2 | | DRAGNS::SAUNDERS | John Saunders, DECdns Engineering, (508) 275-5424 | Thu May 08 1997 14:01 | 17 |
| There appears to be no way to get the STV value from a failing open() call. One
could use _fstat (?) if one had a file handle, but if the open fails, there's no
handle.
It is an interesting suggestion to try the sys$open directly, at least as a
diagnostic tool. It's possible that any use of sys$open fails. I think it's more
likely that any use by us of open() will fail, but that sys$open will succeed.
This note is separate because 5604.* started off as a question about VAXCRTL.EXE
versions, and I mentioned this problem in explaining my reason for asking about
VAXCRTL.EXE. No one looking at NOTES in a year would ever have been able to find
this note by title if I'd left it under the original note.
Thanks,
John Saunders
DECdns Engineering
|
| 5608.3 | | EPS::VANDENHEUVEL | Hein | Wed May 14 1997 11:50 | 17 |
|
- Calling SYS$OPEN directly is the best way to tackle this.
- Have you tried $SET WATCH FILE /CLA=ALL, hoping that it would
display the underelying error message at some point?
- You may want to check out my RMS_CALL_TRACE tool on the VMS
FREEWARE CD (Or VMSZOO::RMS_OPENVMS topic 5.?). If you can
relink without using the VAXCRTL.EXE, but the OLB instead, then
it may help you show STS/STV as RMS is called by the RTL.
Ofcourse you can tweak the trace tool for a (global) flag to
only output stuff for specific IOs.
hth,
Hein.
|