X-Organization: Penn State University / University Libraries
X-Envelope-to: novell@suvm.BITNET
X-VMS-To: NOVELL_L
X-VMS-Cc: NOVELL_PSU
Newsgroups: bit.listserv.novell
Date:         Fri, 22 Jan 1993 10:18:00 EST
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         "J.Lance Wilkinson, 814-865-1818" <JLW@PSULIAS.BITNET>
Subject:      LAN WorkPlace API socket library problems

Environment:  MS-DOS 5.0, Novell Netware 3.11, Novell Lan WorkPlace 4.0,
Borland C++ 3.0

We have an an MS-DOS application we are developing that we wanted to use
LAN WorkPlace's API socket library with.  The sole purpose of the TCP/IP use
will be to query an application-specific TCP/IP port on a host machine to see
if it is accessible, and if so if a particular application is running there,
and report the success or failure to the application's user.

The programmer added the socket library, XLN\TOOLKIT\LIB\SLIBSOCK.LIB, to her
list of object and library files to be linked.  She did not modify her C source
code at all; no calls to the socket libraries functions were added.  Suddenly
her standard C write() function calls began to abort, reporting an errno of 6
(EBADF, bad file number).  She checked and the value of her file handle was
*unchanged* from its value after her previous open().  She removed the socket
library from the list of files to be linked, relinked, and the error went away.
*NO* change to program code, in fact no recompilation; just adding/deleting the
socket library filename from the list of files to be linked, and relinking!

She put the socket library back, then took out her call to write().  The
subsequent close() call failed then, with the same error. She toggled the
inclusing of the socket library from the list of files for the linker, and the
close() worked fine.  She's now put back her call to write() and continuing
with development, *without* the socket libraries.  We're assuming for the time
being that we might have to have the socket library included in a separate
program, which we have to spawn off from within our primary application, unless
we can resolve this.

At no time were *calls* to any of the socket library functions in the program,
meaning that an intelligent linker might have even omitted the socket library
since it wasn't needed.  But something was obviously awry since when the
socket library was included in the link, the errors occured.

Anybody have speculations?  Could the fact we're using Borland instead of
Microsoft be the culprit?  If so, why?  Borland Tech Support had never heard
of such a problem.  Any Novell programmers (Novell employees!) who worked on
Lan WorkPlace have any ideas?

+-"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
| J.Lance Wilkinson ("Lance")            BitNet:    JLW@PSULIAS.BITNET      |
| Systems Design Specialist - Lead       InterNet:  JLW@PSULIAS.PSU.EDU     |
| Library Computing Services         AT&T:(814) 865-1818 FAX:(814)863-3560  |
| E8 Pattee Library                      "I'd rather be dancing..."         |
| Penn State University         A host is a host from coast to coast,       |
| University Park, PA 16802     And no one will talk to a host that's close |
| <POSTMAST@PSULIAS.BITNET>     Unless the host that isn't close            |
| <POSTMAST@PSUCES.BITNET>      Is busy, hung or dead.                      |
+------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU