[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DEC TCP/IP Services for OpenVMS |
| Notice: | Note 2-SSB Kits, 3-FT Kits, 4-Patch Info, 7-QAR System |
| Moderator: | ucxaxp.ucx.lkg.dec.com::TIBBERT |
|
| Created: | Thu Nov 17 1994 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 5568 |
| Total number of notes: | 21492 |
5392.0. "recvfrom() call and "%SYSTEM-F-IVBUFLEN" error..." by AMCUCS::SWIERKOWSKI (Quot homines tot sententiae) Mon Mar 31 1997 15:19
Greetings!
Environment:
------------
$ UCX SHOW VERSION
DEC TCP/IP Services for OpenVMS AXP Version V3.3
on a AlphaServer 2100A 5/300 running OpenVMS V6.2-1H3
Operating System: OpenVMS Alpha V6.2
Problem Description:
--------------------
I'm helping a partner with a problem that he is having with the recvfrom()
function call. He wants to understand the use and abuse of last two arguments
(i.e. "from" and fromlen"). He is seeing the symptoms on both UCX V3.3 and
V4.1 (full output from UCX$VERSIONS.EXE on his UCX V3.3 system is below).
Per the "DEC TCP/IP Services for OpenVMS System Service and C Socket Program-
ming" manual, the "from" argument is described as:
...
from is a buffer where recvfromplaces the address (structure)
of the socket from which the data is received.
If from is nonzero, the address will be returned. If from is 0,
the address will not be returned.
...
What he is seeing is that if he specifies the "from" argument as NULL, then
he gets an "invalid buffer length" error. I asked him for a code snippet and
the sample error output along with the output from UCX$VERSIONS.EXE. Here is
the code snippet he provided:
<--- begin code snippet --->
static void
ft_socket_receive(Opaque unused1, int source, EvmIoId unused2)
{
# define FT_SOCK_BUFLEN sizeof(struct heartbeat)
int len, maxlen = -1;
unsigned int fromlen = 0;
char buf[FT_SOCK_BUFLEN];
char buf1[16];
struct sockaddr_in fromaddr;
#ifndef TIBOS_WIN
errno = 0;
#endif
fromlen = sizeof(struct sockaddr_in);
memset(&fromaddr,0,fromlen);
---->> the following works fine ........
while((len = recvfrom(source, buf,FT_SOCK_BUFLEN, 0,
(struct sockaddr*)&fromaddr, &fromlen)) > 0)
---->> the following gives the invalid buff error .....
/*while((len = recvfrom(source, buf,FT_SOCK_BUFLEN, 0, NULL, &fromlen)) > 0)
*/
{
maxlen = max(len, maxlen);
}
if (maxlen <= 0)
{
perror(":recvfrom");
return;
}
<--- end code snippet --->
Here's the sample error output he provided:
<--- begin sample error output --->
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM: Feed Sources Supported:
97/03/14 16:48:15: GSM: RSF, index = 0
97/03/14 16:48:15: GSM: TELERATE, index = 1
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM: Queue_all_fixed_subjs(): # 0
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM:
97/03/14 16:48:15: GSM: GSM is synchronizing with feed handlers. Please wait.
ft_takeover: Takeover complete in 108 ms.
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
:recvfrom: non-translatable vms error code: 0x34C
%system-f-ivbuflen, invalid buffer length
<--- end sample error output --->
Here's the detailed version information from SYS$SYSTEM:UCX$VERSIONS.EXE he
provided on his UCX V3.3 system (symtoms are the same on a V4.1 system):
<--- begin output from UCX$VERSIONS.EXE --->
$ RUN SYS$SYSTEM:UCX$VERSIONS
DEC TCP/IP Services for OpenVMS AXP Version V3.3
on a AlphaServer 2100A 5/300 running OpenVMS V6.2-1H3
Image Name Image ID Link Date Location
BGDRIVER UCX V3.3-7 4-MAY-1995
SYS$COMMON:[SYS$LDR]
UCX$INETACP UCX V3.3-7 4-MAY-1995 SYS$COMMON:[SYSEXE]
INETDRIVER UCX V3.3-7 18-APR-1995
SYS$COMMON:[SYS$LDR]
UCX$INET_ROUTING UCX V3.3-7 26-APR-1995 SYS$COMMON:[SYSEXE]
UCX$UCXCP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$ACCESS_SHR UCX V3.3-7 4-MAY-1995 SYS$COMMON:[SYSLIB]
UCX$IPC_SHR UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$PING UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$PORTMAPPER UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
SNMP_AGENT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
TELNETCLIENT UCX V3.3-7 26-APR-1995 SYS$COMMON:[SYSEXE]
UCX$TELNETSYM UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
TNDRIVER UCX V3.3-7 26-APR-1995
SYS$COMMON:[SYS$LDR]
RLOGINCLIENT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
RSHCLIENT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$RCP UCX V3.3-7 26-APR-1995 SYS$COMMON:[SYSEXE]
UCX$TRACE UCX V3.3-7 26-APR-1995 SYS$COMMON:[SYSEXE]
UCX$MSG UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSMSG]
UCX$RPCINFO UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$RPCXDR_SHR UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$PWIPDRIVER UCX V3.3-7 18-APR-1995
SYS$COMMON:[SYS$LDR]
UCX$PWIPACP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$PWIPSHUT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX1$SDA UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$BIND_SERVER UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$BIND_SERVER_XFER UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$NSLOOKUP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
NFS_SERVER UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$CFS_SHR UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$DNFSMOUNT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$DNFSDISMOUNT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$DNFSDRIVER UCX V3.3-7 18-APR-1995
SYS$COMMON:[SYS$LDR]
UCX$DNFSACP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
PCNFSD UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
FTPCLIENT UCX V3.3-7 26-APR-1995 SYS$COMMON:[SYSEXE]
FTPC UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
FTPD UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$LPD_RCV UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
LPD_SMB UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$LPQ UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$LPRM UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$LPRSETUP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
LPD_SHR UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$SMTP_RECEIVER UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$SMTP_SYMBIONT UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
SMTP_MAILSHR UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$SMTP_PARSESHR_TV UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSLIB]
UCX$UUENCODE UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$UUDECODE UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
TFTP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
BOOTP UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
UCX$NTPD UCX V3.3-7 18-APR-1995 SYS$COMMON:[SYSEXE]
<--- end output from UCX$VERSIONS.EXE --->
I researched this in this conference and in COMETS and nothing with this error
output jumped out at me (note 936.* does demonstrates the "%system-f-ivbuflen"
error, but in conjunction with the getsockopt() call on a UCX V2.0 system). I
saw no other references to the "%system-f-ivbuflen" error in conjunction with
the recvfrom() call on UCX V3.3 (or V4.1 for that matter.) I've gone through
the release notes for ECO 1, 2 & 4 on UCX V4.1 and found no reference to this
sort of problem and per the customer he hasn't installed any ECO's on his UCX
V4.1 environment. I don't remeber enough about UCX V3.3 to know if the above
output from UCX$VERSIONS.EXE shows one or more ECO kits has been applied or not.
I don't understand the code snippet well enough to see anything obviously
wrong in the way he is using recvfrom(), but the customer doesn't believe he
has made a fundamental programming error. FWIW, I did not that in all the
sample programs I've compared his code to, they do have one thing in common:
they *ALWAYS* specify the "from" argument as non-NULL. His failure mode is
only exhibited when the "from" argument is NULL, but if I understand the
documentation this should be okay. I'd sure appreciate any help on this, I
have no idea what to try or suggest next. If you need more information, please
call, send email or reply to this note, cheers...
Tony Swierkowski
Digital Equipment Corporation
Software Partner Engineering
Palo Alto, California
(415) 617-3601
"[email protected]"
| T.R | Title | User | Personal
Name | Date | Lines
|
|---|