| From: DEC:.REO.JOLLY::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 4-JUN-1997 14:05:18.47
To: nm%vbormc::"[email protected]"
CC: HUDSON
Subj: libcxxstd.olb
Hello Jan Sunneb�ck
>We are going to take over the support of a product which is written in DEC
>C++. We have always distributed our software in object form (obj, olb) which
>is then linked at the customer site. This C++ product, however, requires an
>object library, libcxxstd.olb which we cannot find as being part of a normal
>OpenVMS installation without C++ installed. The module included from this
>library is cxx_std_init. Is this something that should be distributed with
>VMS or is it just bad programming technique used by the developer of this
>product?
LIBCXXSTD.OLB contains modules which provide support for the standard template
library and for run-time exception handling. This file comes with the C++
installation, but does not ship with VMS, as you say. I guess that if you're
getting problems of the type you mention, then your code is using run-time
exception handling (or maybe STL functionality).
The C++ engineering group say that although the SPD doesn't specifically
mention it, the intent is to allow redistribution of run-time of LIBCXXSTD.OLB,
so this may be something that would fix your problem.
I believe that the "CXXLINK" command automatically pulls in symbols from
LIBCXXSTD.OLB, and so the implication is that you are using CXXLINK to build
your C++ code on your own machines. But CXXLINK does other stuff too (such as
template instantiation), and redistribution of CXXLINK is not permitted. So if
you need that then there could be problems.
Perhaps let me know whether you need CXXLINK functionality, or whether being
able to give your customers LIBCXXSTD.OLB is a satisfactory solution.
Regards
nick
|
| From: DEC:.REO.JOLLY::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 4-JUN-1997 16:13:13.78
To: nm%vbormc::"[email protected]"
CC: HUDSON
Subj: file access over tcp/ip
Hello Jan Sunneb�ck
>Will UCX in any planned version contain any of the features available with
>Multinet Phase/IP, specifically the remote file access?
I don't think I know enough about what you're doing (or Multinet Phase/IP) to
be able to answer this question.
>In your answer you also said that "writing an equivalent to FAL might not be
>too difficult if all you want to do is reading data". What I actually would
>like to do is Block I/O, i.e. reading and writing specified data blocks of
>2K. I'm not quite sure if writing data is a mandatory requirement, though.
>Do you consider this to still be "not too difficult" if I need to write
>myself a FAL equivalent?
I don't think it would be difficult to write an tcp/ip based application that
would let you do reading/writing of data blocks of 2K. It gets more difficult
as you try and make the application more general purpose, and less rigid in
what it allows.
With the file access listener (FAL, that is the program that runs when you do a
remote file operation over DECnet), VMS has supplied a generic, ready-to-use,
way to access files remotely, and all VMS systems "know" how to use it. If
you want to access files remotely over TCP/IP, you have to do it yourself.
For example, assume you have a situation where you have a server node that
maintains a file, FRED.DAT, and multiple client nodes which want access to that
file. Assuming you are writing the server software and the client software,
then a very simple server would do something like:
open FRED.DAT using RMS
set up a socket, and bind it to a particular port
loop: listen on that socket, waiting for clients
when a client connects -
read message from client
read or write data to/from data file depending on message type
send response to client
goto loop
When the client wants to read/write data to the file on the server, it would
do:
create a socket
connect to port on server
send message
wait for acknowledgement
close socket
Your "message" could be constructed in such a way as to contain information as
to
a) record number you want to access of file
b) whether it's a read or write
c) if it's a write, the data you want to write
Obviously, this is a very non-general case (the client can only access one data
file, etc.). By defining a message format of greater complexity you could
increase the power of this setup, but in all cases, you have to write the
client and server to obey the rules about what information your messages
contain.
If you wanted to be able to duplicate all the functionality that RMS/FAL give
you, then the messages going between your client and server would have to
contain a lot more information (file name, file access method, file operation,
etc.) and so the client/server would have to be a lot more complicated.
Also, whereas all VMS systems "know" how to talk RMS across DECnet, only
systems that understand your message protocol could use your server. So you
couldn't say to someone "use port 12345 on server fred to get at the data",
you'd have to say "here is some code that will talk to port 12345 on server
fred and let you access the data", or "here is a description of the message
format that the server using port 12345 on node fred is expecting; write an
application that uses this format of message".
You also have to make sure that your server is running, whereas on VMS then FAL
processes get started automatically when incoming requests appear, etc..
I hope this helps explain my earlier qualified comment of "not too difficult".
If you need more information, perhaps you could describe exactly what you want
to achieve.
Regards
Nick Hudson
Digital Software Partner Engineering
|