| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5186.1 | | COMEUP::SIMMONDS | lock (M); while (not *SOMETHING) { Wait(C,M); } unlock(M) | Mon Feb 03 1997 21:54 | 7 |
| [I should defer 'til John Geminiani answers this, but.. ;)]
The ONC RPC package was apparently substantially improved for UCX
V4.0, eliminating nasties like this one.. best to get your Customer
onto the latest versions (UCX V4.1 +ECO4, DEC C V5.5) ..I see no
such problems with the newer versions I just mentioned.
John.
|
| 5186.2 | | VIRGIN::PFISTERR | Carpe Diem, Memento Mori | Mon Feb 10 1997 02:55 | 10 |
| The customer answered to me:
The only problem is, that a program which is developed
under V4.1 is not able to link or run under UCX 3.x.
All our production systems have UCX 3.x installed.
I hope this shows you a little bit our problem with
this software.
->What can he do?
|
| 5186.3 | | VIRGIN::PFISTERR | Carpe Diem, Memento Mori | Tue Feb 11 1997 02:25 | 5 |
| Here I am again!
What about the workaround which is from TURRIS::DECC #2072 (modify
UCX$RPCXDR.H to include socket.h)? Or do You have another solution?
Rene
|
| 5186.4 | | UCXAXP::GEMIGNANI | | Tue Feb 11 1997 20:07 | 12 |
| It could very well work.
The problem is that the V4.1 code is built to run with DECC. The V3.3
RPC uses VAXC. Does the customer have DECC or VAXC installed on their
systems?
I would recommend that you stay away from modifying the header files of
UCX. If you could, have the socket.h header included into the user's
application, this way it will always work independent of the
environment that it is built in.
Am I on the mark here?
|
| 5186.5 | I think the answer was no | HNDYMN::MCCARTHY | A Quinn Martin Production | Wed Feb 12 1997 06:23 | 5 |
| I think it was mentioned in the turris::c_plus_plus version of this thread that
the customer had "a great deal" of files to change and wanted a fix from
Digital instead.
bjm
|
| 5186.6 | UCX$RPCXDR_SHR.EXE Compiler Erroring Out | CSC32::P_DICKERSON | | Wed Feb 12 1997 13:55 | 19 |
|
Hi,
I have a customer that actually read the release notes. It told her
to rebuild UCX$RPCXDR_SHR.EXE with DEC C. But it is erroring out on
her. Therefore, she is using the old UCX$RPCXDR_SHR.EXE. This works
fine for her. Her questions are:
1. Will using an old version of UCX$RPCXDR_SHR.EXE have any kind of
effect on the new version of UCX or her applications when she uses
RPC?
2. What can she do to get the compiler to successfully rebuild a new
UCX$RPCXDR_SHR.EXE?
Please advice,
Phil D.
|
| 5186.7 | | LASSIE::GEMIGNANI | | Tue Feb 18 1997 16:42 | 28 |
| I just did a search of the socket.h inclusion, and found that ...
UCX$RPCXDR.H includes UCX$RPC:rpc.h
UCX$RPC:rpc.h includes UCX$RPC:types.h
UCX$RPC:types.h includes <socket.h>:
#ifndef __SOCKET_TYPEDEFS
#include <socket.h>
#endif /* __SOCKET_TYPEDEFS */
So, socket.h should be included in the user's compilation. You can
defeat this inclusion by including UCX$RPCXDR.H AFTER your own
inclusion of <socket.h>.
Regarding questions posed in .6:
1) The older RPC library could have some routine mismatches if you
compile with V4 and link to run with V3. There are also a series
of features which are not present in that library.
2) There is no way for a customer to build a copy of UCX$RPCXDR_SHR.EXE
at their site.
If you are developing on a V4 system and installing on V3 systems, you
should link against UCX$RPC:UCX$RPCXDR.OLB. This means that you won't
need to use the UCX$RPCXDR_SHR.EXE image at all. Hence, there should
be no image incompatibilities. The protocol for V3 and V4 are
identical, so the RPC will work without any problems.
|
| 5186.8 | we would consider this our bug | HNDYMN::MCCARTHY | A Quinn Martin Production | Wed Feb 19 1997 05:42 | 8 |
| The C++ Class Library and the CRTL have requirements that each of its
header files compile "stand alone". This means that if the header file
requires another header file, it includes it.
I would hope UCX would adopt the same requirement (ie if rpc.h needs socket.h,
it includes it).
bjm
|
| 5186.9 | | LASSIE::GEMIGNANI | | Wed Feb 19 1997 18:46 | 16 |
|
I am soooo disappointed. You claimed it to be your bug, and you don't
want to argue about it first.
We are in the process of designing IP V6 support for UCX, and a whole
bunch of new IP definitions are going to be needed. It is my belief
that the networking header files should come from us (i.e. socket.h,
in.h, netdb.h, etc, etc, etc). A lot of this is too much out of our
control. In this case, there are a bunch of definitions in the network
header files which we have no control over, and they are different than
other implementations (granted, if you wanted Unix you would have
installed it instead of VMS). The issues we get beat up upon (and this
is one of them) is around portability. We have to be sure to be
portable with Unix, in particular.
So where do we go now?
|
| 5186.10 | The End. | UCXAXP::GEMIGNANI | | Thu Feb 20 1997 15:57 | 21 |
|
And, in conclusion ...
What we have here is a simple incompatibility between V3 and V4, in
that the customer is compiling on V4 and expects to be able to link
against the V3 shareable.
The release notes state that you must use DECC beginning with V4.
It recommends that you compile (or at least relink) your apps to use
the new shareable. At installation time, the old shareable is
preserved (and the installation procedure tells you this), in case you
need to use it for older programs. Granted, it wasn't nice to have
to require this, but a solution is now in place which will apply to
all future releases.
In .7, I suggested a workaround which would ensure that your code could
work on any version of UCX. Another group within Digital has used this
approach and it works fine for them. Keep in mind that this particular
problem occurs with UCX V3.3 systems, and we no longer support this
release.
|