Please, does anyone know which mv database products have TCP socket
communications available from Databasic?

Thanks

I think they all do, except for maybe mvBase. Not sure `bout that. UV, UD,
D3, QM, jBase, and Reality all have dataBASIC socket functions or pass-thru
functions for the C socket routines. If you plan on writing a socket
service, then you need to heed the warnings of ghosts of services past.
Writing a multi-client socket service in dataBASIC is not a straight-forward
thing. Post some info on what you are planning to do and I can give you some
pointers that will save you weeks of mis-routed code and hair-pulling. My
favorite tool for creating socket services is inetd/xinetd or Winetd for
Windows. Any text console app can be automagically turned into a stable
socket service.

Glen
http://mvdevcentral.com
http://picksource.com


"Steve" <132ji433 (AT) donotspamme (DOT) com> wrote

For example (D3), see
GPTerm.PHANTOMPRG and all GPTerm.PHANTOM* subroutines in BRIZ library.
http://mvdevcentral.com/projects/pebriz or
http://infotools.ru/products/BRIZ/briz_download.htm
(Provides communication at work on phantoms)

Best regards, Grigory

Having spent a lot of time with sockets, I'll echo Glen's comments (so
what else is new?), but I have to remark on the original question
"which MV platforms support sockets?" Are you planning to start using
some MV platform depending on whether it supports sockets? That's not
the right way to go about things and I suspect your real question has
nothing to do with this at all.

Also you don't mention if you're looking for an MV app to be a socket
client or socket server. There are good alternatives to writing your
own socket code, including free comms components, buying special
purpose components (HTTP, NNTP, SMTP, POP3, IRC...), or buying stable
and supported tools that might cost just a couple hundred dollars and
save you months of custom development. Please let us know what you're
really doing and we'll be able to give you a much better answer.

Tony


"Glen B" <webmaster.at.allspec.com> wrote:

MVEnterprise doesn't have the ability to talk to sockets. We've had to
develop our own using java.
My 5 cents input...

regards
i.

Tony Gravagno wrote:

Thanks to all for the comments. I simply need to run some existing generic
Databasic code, which is proven and tested, on any mv platform which will
enable me to talk to an IP service on the network.

In other words, I want to retain this application which runs on Pick and I
don't want to change the way it works, other than to hook in some code to
talk to an IP service. Simple as that really.

Steve

That's not a hard task and it should be doable on most of the flavors
except for the MV<name> products. Doug wrote a TCP stack in Pick assembler,
which also runs on mvBase, mvEnterprise, etc. Stop by www.modsoft.com and
check out PicLan-IP. You can run that TCP/IP tool set on just about any
flavor of Pick, so you can simplify your integration. If you plan on writing
for just a couple flavors that support sockets, then it may be worth
checking out my precompiler. It's still in pre-alpha, but the flavor
directives work well. http://mvprecompiler.mvdevcentral.com/ The LOOP
directive needs a lot of work so don't plan on using it. I would write your
socket I/O subs outside of the main application, so you can use a
precompiler to generate flavor-specific socket code as needed without a lot
of hassle.

Some Pick socket functions require that you do things to make them work
properly. Under D3, you should set the %read() buffer's variable to
max-length of whitespace before you call the function. If you are reading
100 byte blocks, then you should do BUFFER = SPACE(100) before using BUFFER
in the read statement. This forces a malloc to the proper memory size for
the %read() function's buffer. If you don't do that everytime, then you can
get data corruption. I've seen it myself on large buffer sizes. You may be
able to get away without doing it, but some heavy testing should be done to
make sure the code is going to work properly. I would ask about things like
this, regarding all flavors you plan on writing for.

Are you familiar with using Unix sockets and Windows sockets, as well as
the differences between them? If you're not, then I don't recommend that you
jump in with both feet. Most of the flavors wrap the C socket calls into
their own functions, but there are always inherent limitations to consider.
Client side development isn't that difficult to deal with, but there are
still the issues of function blocking and code control/error control. Most
of the systems default to blocking functions, so you can't just poll the
read() function and wait for a certain error code. Certain flavors implement
setsockopt totally differently than the normal C style, while others follow
the same syntax but leave out several key option values due to platform
incompatibility. Basically, you've got a lot of homework to do!

Glen
http://mvdevcentral.com
http://picksource.com

"Steve" <132ji433 (AT) donotspamme (DOT) com> wrote

Or, rather than coding to sockets from MV, Steve can shell out to
execute a network written at the OS level. This eliminates a lot of
MV-specific issues which may not be resolvable, eliminates a lot of
platform-specific code, and puts the burden of compliance at the OS
level, where we know most/all of the issues have already been worked
out and qualified help is abundant. It's also usable by any
non-native MV DBMS, though solutions are available for native
platforms as well.

For example, I've built a few interfaces around cURL where I write
data to the OS, call cURL for an HTTP, FTP, or other protocol
exchange, then read back the resulting data from the OS. This is not
a time-painful process as some people might think. Unless you're in
an environment which is absolutely millisecond intensive then this
isn't a real concern. Even if you are in such an environment (most
people think they are), many sub-applications within such environments
are still not concerned with the extra couple milliseconds per
transaction lost in this handshaking with the OS.

In addition to cURL, I use Perl, .NET, VB, or other components and
technologies to accomplish the same goals. The solution depends on
the platform and what protocol(s) can be used. And FWIW, if you're
doing platform X to platform Y transactions then you're an excellent
candidate for Web Services, especially over an intranet.

Just ideas...
HTH,
Tony
TG@ removethisNebula-RnD
..com


"Glen B" <webmaster.at.allspec.com> wrote: