| 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 |
I heard from MCS person that UCX has a OpenVMS Delta Time problem for RPC and NFS. However I don't find any information in this notesfile. Do you have any information ? (Of course, I hope I have a uncorrect information. Even though it's ture, we can not provide UCX to all customers before 19-MAY.) Ryouzo
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5417.1 | CGOOA::OWONG | SKIWI in Canada (VAO) | Tue Apr 08 1997 01:59 | 6 | |
I'm not sure about the components you talk about but
www.openvms.digital.com talks about DCE and DECthreads as well as
applications that call some of the LIB$ routines. Check out that
location if you haven't already.
Owen.
| |||||
| 5417.2 | check this one | VIRGIN::BASSI | Tue Apr 08 1997 07:21 | 10 | |
Hi Ryouzo,
try to check entry 5007.*, maybe that's what you are looking for.
Best regards.
Gianbattista
| |||||
| 5417.3 | Situation in detail | TKOVOA::MATSUNO_R | Tue Apr 08 1997 08:08 | 25 | |
Hi all, thank you for information.
I had a little more information from MCS person. He found the just Delta Time
problem coding on RPC/XDR source of UCX. And he contacted to the programmer
of this code, then he received from that programmer he had known this issue
and he would provided ECO.(I have a mail, but I don't have approval of going
public.)
However I got a another mail between Japanese Engineering Group(Localization)
and UCX Project Team. In the mail, UCX team don't know any Delta Time issue
on UCX.
We were confused. Also, some person talked to several sales person about this
situation. I have to tell the story of UCX and Delta Time to our sales
person.
I'd like to know 2 points.
(1) UCX has a Delta Time issue or not ?
(2) If there exists, when ECO is available ? Of course, we need the previous
UCX ECO.
Ryouzo
| |||||
| 5417.4 | Stand back or ... or ... I'll go public! | UCXAXP::GEMIGNANI | Tue Apr 08 1997 19:32 | 2 | |
I know of the problem and will be providing an ECO.
| |||||
| 5417.5 | One question | TKOVOA::MATSUNO_R | Tue Apr 08 1997 21:13 | 18 | |
>> <<< UCXAXP::GEMIGNANI �ˤ��Ρ��� 5417.4 >>> >> -< Stand back or ... or ... I'll go public! >- >> >> >> I know of the problem and will be providing an ECO. Thank you for your reply. I'd like to know one point at this time. What thing does this problem cause ? All applications using RPC may stop suddenly on 19-MAY. Or there may be several troubles, but slight damege. My point is whether we have to provide the patch of Delta Time to all customers using UCX or we can specify who will need the patch. I will appreciate for your reply. Ryouzo | |||||
| 5417.6 | LASSIE::GEMIGNANI | Thu Apr 10 1997 19:32 | 23 | ||
Actually, it's not what you would think.
The code to do time determination (a local `gettimeofday()' routine) is
actually in error. The resulting time [using LIB$SUB_TIMES()] is a
delta time, and is therefore a large value (being an otherwise negative
number).
The time value is used for unix authentication, by placing tv_sec into
the authentication time field. This is not significant, first of all,
because the time in the RPC source does not look like it is being
adjusted for GMT, as one would expect. Secondly, there has never been
a problem with this code and we (in UCX), never check this field
anywhere (because it's not in GMT).
The time also appears to be used to generate a unique XID in the TCP,
UDP and PMAP code. It's meant as a `salt' for a `reasonably random'
number. This means that it's not an issue, since there doesn't appear
to be guard code to guarantee that it is unique.
AND, IN SUMMARY ...
In my opinion, there should be no difference and it doesn't appear that
RPC is going to be vicimized in any way by this mishap.
| |||||