[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DCE Product Information |
| Notice: | Kit Info - See 2.*-4.* |
| Moderator: | TUXEDO::MAZZAFERRO |
|
| Created: | Fri Jun 26 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2269 |
| Total number of notes: | 10003 |
2237.0. "DCE truncating strings" by LORDS::COLE (Share and enjoy) Tue Apr 29 1997 07:17
Can anyone help oue of our partners. They inclosed the following letter.
Many thanks,
Simon
We have a technical problem that deals with the DCE 1.4 software in
OpenVMS Alpha V7.1 environment. (DCE$LIB_SHR.EXE ident is V1.4-961030).
The problem is with the remote procedure calls (DCE/RPC). Seems that
long output strings from RPCs are not delivered correctly by the
software.
For example, I have the following RPC definition:
void t_gets(
[in] handle_t rpch,
[in] long cRetStrMax,
[string,out,size_is(cRetStrMax)] char *szRetStr);
and I call it as follows:
idl_char txt[512];
t_gets(rpch, sizeof(txt), txt);
the length of the result string is 300, but only 220 characters are
seen
by the client routine. The above is part of my simple example. A more
complex
example also seems to corrupt the program somehow.
The same program works OK in OpenVMS Alpha 6.2 with DCE version 1.2 (
DCE$LIB_SHR.EXE ident is "DCE V1.2-940507"). The example works also
if
the server is in OpenVMS Alpha 6.2/DCE 1.2, and only the client is in
OpenVMS Alpha V7.1/DCE 1.4, so it seems that the problem is in the
server's side.
Is this a bug in the DCE/RPC software? Is there any remedial kits for
it?
You can contact me as follows:
e-mail: [email protected]
tel: +358 10 222 5282
fax: +358 10 222 5210
The sources for the complete example program follows:
T_BUILD.COM - builds the example
T_CLIENT.C
T_CLIENTL.COM
T_COM.COM - defines t_server and t_client commands
T_IF.H
T_IF.IDL
T_MANAGER.C
T_OUTPUT.TXT - output example from my environment
T_SERVER.C
T_SERVERL.COM
Make a command procedure from the following, and run in
an empty directory to create the example files.
------------------------------ cut here
------------------------------
$ C:=CREATE/LOG
$ C T_BUILD.COM
$ DECK/DOLLARS=___$$$___
$ IDL -keep c_source T_IF.IDL -trace all
$ CC/INC=<> T_SERVER.C
$ CC/INC=<> T_MANAGER.C
$ CC/INC=<> T_IF_SSTUB.C
$ CC/INC=<> T_IF_CSTUB.C
$ CC/INC=<> T_CLIENT.C
$ @T_SERVERL.COM
$ @T_CLIENTL.COM
___$$$___
$ C T_CLIENT.C
$ DECK/DOLLARS=___$$$___
/*=====================================================================
=======
==
t_client.c
=======================================================================
=======
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "t_if.h"
#include <dce/dce_error.h>
typedef struct
{
idl_char bytes[dce_c_error_string_len];
} errstr_store_rec;
/*---------------------------------------------------------------------
-------
--
-----------------------------------------------------------------------
-------
*/
static idl_char *GetDceErrText(error_status_t st, errstr_store_rec
*str_store)
{
int retst;
dce_error_inq_text(st, str_store->bytes, &retst);
return str_store->bytes;
}
/*---------------------------------------------------------------------
-------
--
-----------------------------------------------------------------------
-------
*/
static void Exercise(
rpc_binding_handle_t rpch)
{
idl_char txt[512];
t_gets(rpch, sizeof(txt), txt);
printf("Text = '%s'\n", txt);
}
/*---------------------------------------------------------------------
-------
--
-----------------------------------------------------------------------
-------
*/
static void TestMain(int argc, char **argv)
{
rpc_binding_handle_t bh;
error_status_t st;
idl_char *string_binding;
errstr_store_rec errstr;
if (argc >= 2)
{
string_binding = (idl_char*) argv[1];
}
else
{
string_binding = (idl_char*) "ncacn_ip_tcp:138.221.156.11";
}
printf("Connecting to string binding '%s' ...\n", string_binding);
rpc_binding_from_string_binding(string_binding, &bh, &st);
if (st != error_status_ok)
{
fprintf(stderr, "Invalid address '%s' - %s\n", string_binding,
GetDceErrText(st, &errstr));
exit(2);
}
printf("Bound to %s, rpch = %d\n", string_binding, bh);
Exercise(bh);
rpc_binding_free(&bh, &st);
if (st != error_status_ok)
{
fprintf(stderr, "Failed to execute rpc_binding_free - %s\n",
GetDceErrText(st, &errstr));
exit(2);
}
puts("Binding freed");
}
main(int argc, char **argv)
{
TestMain(argc, argv);
return 1;
}
___$$$___
$ C T_CLIENTL.COM
$ DECK/DOLLARS=___$$$___
$ LINK'P1'/EXE=t_client.exe -
t_client,T_IF_CSTUB,-
dce:dce.opt/options
___$$$___
$ C T_COM.COM
$ DECK/DOLLARS=___$$$___
$ t_server :== $sys$disk:<>t_server
$ t_client :== $sys$disk:<>t_client
___$$$___
$ C T_IF.H
$ DECK/DOLLARS=___$$$___
/* Generated by IDL compiler version DEC DCE T1.2.0-06 */
#ifndef t_if_v1_0_included
#define t_if_v1_0_included
#ifndef IDLBASE_H
#include <dce/idlbase.h>
#endif
#include <dce/rpc.h>
#ifdef __cplusplus
extern "C" {
#endif
#ifndef nbase_v0_0_included
#include <dce/nbase.h>
#endif
extern void t_gets(
#ifdef IDL_PROTOTYPES
/* [in] */ handle_t rpch,
/* [in] */ idl_long_int cRetStrMax,
/* [out] */ idl_char *szRetStr
#endif
);
#if defined(__VMS) && (defined(__DECC) || defined(__cplusplus))
#pragma extern_model __save
#pragma extern_model __common_block __shr
#endif
typedef struct t_if_v1_0_epv_t {
void (*t_gets)(
#ifdef IDL_PROTOTYPES
/* [in] */ handle_t rpch,
/* [in] */ idl_long_int cRetStrMax,
/* [out] */ idl_char *szRetStr
#endif
);
} t_if_v1_0_epv_t;
extern rpc_if_handle_t t_if_v1_0_c_ifspec;
extern rpc_if_handle_t t_if_v1_0_s_ifspec;
#if defined(__VMS) && (defined(__DECC) || defined(__cplusplus))
#pragma extern_model __restore
#endif
#ifdef __cplusplus
}
#else
#endif
#endif
___$$$___
$ C T_IF.IDL
$ DECK/DOLLARS=___$$$___
/*=====================================================================
=======
==
t_if.idl
=======================================================================
=======
*/
[
uuid(f5ef0a53-bc8d-11d0-9104-08002b9138c5),
version(1.0)
]
interface t_if
{
void t_gets(
[in] handle_t rpch,
[in] long cRetStrMax,
[string,out,size_is(cRetStrMax)] char *szRetStr);
}
___$$$___
$ C T_MANAGER.C
$ DECK/DOLLARS=___$$$___
/*=====================================================================
=======
==
t_manager.c
=======================================================================
=======
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include "t_if.h"
/*---------------------------------------------------------------------
-------
--
-----------------------------------------------------------------------
-------
*/
extern void t_gets(
/* [in] */ handle_t rpch,
/* [in] */ idl_long_int cRetStrMax,
/* [out] */ idl_char *szRetStr)
{
assert(cRetStrMax >= 301);
memset(szRetStr, 'A', 100);
memset(szRetStr+100, 'B', 100);
memset(szRetStr+200, 'C', 100);
szRetStr[300] = 0;
printf("Returning '%s'\n", szRetStr);
}
___$$$___
$ C T_OUTPUT.TXT
$ DECK/DOLLARS=___$$$___
Server output:
PXPS02$ RPC_LOG_FILE == " "
PXPS02$ t_server ncacn_ip_tcp
Bindings:
ncacn_ip_tcp:138.221.156.12[2842]
Listening...
1997-04-24-13:54:21.396+03:00I----- PXPS02:761266657/0 t_if.t_gets
log_start all
1997-04-24-13:54:21.424+03:00I----- PXPS02:761266657/0 t_if.t_gets
activate ncacn_ip_tcp:138.221.156.12[
2844]
1997-04-24-13:54:21.427+03:00I----- PXPS02:761266657/0 t_if.t_gets
manager_call
Returning
'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBB
BCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC'
1997-04-24-13:54:21.450+03:00I----- PXPS02:761266657/0 t_if.t_gets
manager_return
1997-04-24-13:54:21.453+03:00I----- PXPS02:761266657/0 t_if.t_gets
terminate
Client output:
PXPS02$ RPC_LOG_FILE == " "
PXPS02$ t_client ncacn_ip_tcp:138.221.156.12[2842]
Connecting to string binding 'ncacn_ip_tcp:138.221.156.12[2842]' ...
Bound to ncacn_ip_tcp:138.221.156.12[2842], rpch = 7338048
1997-04-24-13:54:21.359+03:00I----- PXPS02:761274150/0 t_if.t_gets
log_start all
1997-04-24-13:54:21.369+03:00I----- PXPS02:761274150/0 t_if.t_gets
call_start ncacn_ip_tcp:138.221.156.12[
2842]
1997-04-24-13:54:21.380+03:00I----- PXPS02:761274150/0 t_if.t_gets
await_reply
1997-04-24-13:54:21.458+03:00I----- PXPS02:761274150/0 t_if.t_gets
receive
1997-04-24-13:54:21.461+03:00I----- PXPS02:761274150/0 t_if.t_gets
call_end
Text =
'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBCC
CCCCCCCCCCCCCCCCCC'
Binding freed
___$$$___
$ C T_SERVER.C
$ DECK/DOLLARS=___$$$___
#include <stdio.h>
#include <stdlib.h>
#include <dce/dce_error.h>
#include <dce/exc_handling.h>
#include "t_if.h" /* header file generated by IDL compiler */
#define MAX_CONCURRENT_CALLS 1
extern t_if_v1_0_epv_t t_v1_0_manager_epv;
static uuid_t uuid_nil;
typedef struct
{
idl_char bytes[dce_c_error_string_len];
} errstr_store_rec;
/*---------------------------------------------------------------------
-------
--
-----------------------------------------------------------------------
-------
*/
idl_char *GetDceErrText(error_status_t st, errstr_store_rec
*str_store)
{
int retst;
dce_error_inq_text(st, str_store->bytes, &retst);
return str_store->bytes;
}
/*---------------------------------------------------------------------
-------
--
-----------------------------------------------------------------------
-------
*/
static int main(int argc, char **argv)
{
rpc_binding_vector_p_t bvec;
error_status_t st;
idl_boolean validfamily;
idl_char *protSeq;
int bindi;
idl_char *string_binding;
errstr_store_rec errstr;
if (argc != 2)
{
fprintf(stderr, "Usage: %s family\n", argv[0]);
exit(2);
}
protSeq = (idl_char*) argv[1];
validfamily = rpc_network_is_protseq_valid(protSeq, &st);
if (st != error_status_ok)
{
fprintf(stderr, "Cannot check protocol sequence - %s\n",
GetDceErrText(st, &errstr));
exit(2);
}
if (!validfamily)
{
fprintf(stderr, "Protocol sequence '%s' is not valid\n",
protSeq);
exit(2);
}
rpc_server_use_protseq(protSeq, MAX_CONCURRENT_CALLS, &st);
if (st != error_status_ok)
{
fprintf(stderr, "Cannot use protocol sequence - %s\n",
GetDceErrText(st,
&errstr));
exit(2);
}
rpc_server_register_if(t_if_v1_0_s_ifspec, &uuid_nil, NULL, &st);
if (st != error_status_ok)
{
fprintf(stderr, "Cannot register interface - %s\n",
GetDceErrText(st,
&errstr));
exit(2);
}
rpc_server_inq_bindings(&bvec, &st);
if (st != error_status_ok)
{
fprintf(stderr, "Cannot inquire bindings - %s\n",
GetDceErrText(st,
&errstr));
exit(2);
}
printf("Bindings:\n");
for (bindi = 0; bindi < bvec->count; bindi++)
{
rpc_binding_to_string_binding(bvec->binding_h[bindi],
&string_binding,
&st);
printf("%s\n", string_binding);
rpc_string_free(&string_binding, &st);
}
rpc_ep_register(t_if_v1_0_s_ifspec, bvec, (uuid_vector_p_t) NULL,
(unsigned_char_p_t) "t version 1.0 server", &st);
if (st != error_status_ok)
{
fprintf(stderr, "Could not register endpoint - %s\n",
GetDceErrText(st,
&errstr));
}
TRY
{
printf("Listening...\n");
rpc_server_listen(MAX_CONCURRENT_CALLS, &st);
if (st != error_status_ok)
{
fprintf(stderr, "Error: %s\n", GetDceErrText(st, &errstr));
exit(2);
}
}
CATCH_ALL
{
printf("Unregistered endpoint\n");
rpc_ep_unregister(t_if_v1_0_s_ifspec, bvec, (uuid_vector_p_t)
NULL,
&st);
}
ENDTRY;
}
___$$$___
$ C T_SERVERL.COM
$ DECK/DOLLARS=___$$$___
$ LINK'P1'/EXE=t_server.exe -
T_SERVER.OBJ, -
T_MANAGER.OBJ, -
T_IF_SSTUB,-
dce:dce.opt/options
___$$$___
------------------------------ cut here
------------------------------
In replying, please use [email protected]
RFC-822-headers:
Received: from reoexc1.reo.dec.com by rg71rw.reo.dec.com (PMDF V5.0-7 #15552)
id <[email protected]> for [email protected]; Thu,
24 Apr 1997 15:15:06 +0100
Received: by reoexc1.reo.dec.com with SMTP
(Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
id <[email protected]>; Thu, 24 Apr 1997 15:16:49 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2237.1 | Will look into this... | STAR::SWEENEY | | Mon May 05 1997 14:20 | 4 |
|
I'll test this out. There is no remedial fix for this problem as this is the first report.
Dave
|
| 2237.2 | More info form Partner | LORDS::COLE | Share and enjoy | Mon May 12 1997 05:21 | 8 |
| Any news yet? I guess that you are able to reproduce the problem
with my example. I have found one other thing: the problem is not
only in the server's side. The same problem occurs when a
DCE 1.4 client is calling a DCE 1.2 server, and there is an [in]
array parameter (at least when using the size_is() -attribute).
Regards,
|
| 2237.3 | Example server and client does not reproduce the problem | STAR::SWEENEY | | Tue May 13 1997 16:41 | 13 |
|
I've run the example server and client code without seeing the truncation problem. I ran with the following
configurations:
. V1.4 Alpha server on V7.1, V1.4 client Alpha V6.2
. V1.4 Alpha server on V7.1, V1.3B client on VAX 6.2
. V1.4 Alpha client on V7.1, V1.3B server on VAX 6.2
I did not see the problem. DCE 1.2 is unsupported and may be the source of the problem. Your partner should
upgrade from 1.2. If you are able to reproduce this problem using the supported OpenVMS versions, please let me
know. The supported versions are V1.4 and V1.3B.
Dave
|
| 2237.4 | More info | LORDS::COLE | Share and enjoy | Thu May 29 1997 06:29 | 100 |
| From: VBORMC::"[email protected]" "Jari Kulmala" 29-MAY-1997
10:12:56.54
To: "Simon Cole 830 4084 - Software Partner Engineering
[email protected]" <[email protected]>
CC:
Subj: Re: DCE problem
>
> Please let me see if I have understood things correctly.
>
> You have a mixed system running V1.2 and v1.4 and it does not work. - TRUE,
but...
>
> An engineer here has run your code with V1.4 on both sides and it does work.
- So the problem must be due to our environment and not to the DCE version
>
> DCE V1.2 has been replaced by later versions and is no longer supported.
- I understand
>
> Please let me know If my understanding of your situation is in error. - Yes,
partly
Here is the full story:
We had a OpenVMS 7.0 Alpha, and DCE 1.3, and everything worked fine. We have a
mixed system in the sense that our VMS cluster contains both OpenVMS 6.2 and
OpenVMS 7.0
computers. However, if you mean with mixed system the mixing of versions between
the client and server side of the DCE/RPC application, this is not the case. DCE
server and
client programs were in the SAME computer, the one that run OpenVMS 7.0.
Then we upgraded to OpenVMS 7.1, and to DCE 1.4, and the application stopped
working.
The application was a server process for our own database product.
Because the application is very large, I prepered a tiny example that revealed
the problem.
All this I did in the OpenVMS 7.1 computer, with DCE 1.4 in it.
In order to be helpful, I also tested the example application in OpenVMS 6.2
with DCE 1.2,
which I happened to be able to access. I also tested the application by running
the server
and client in different versions. You may find the results of these tests from my
original problem submission.
Now, because you can not reproduce the problem, the problem must be caused by
some
component in our OpenVMS 7.1 system. I sent the MAP listing of the linking on
23.5.1997,
from which you can se the exact versions of the run time libraries that the
application
uses.
Also, I heard that a new OpenVMS 7.1 computer will be installed in our office
soon, so
I can test the application also there. Hopefully we together will find a solution
to this problem.
Regards, Jari Kulmala.
Ps. the application for which I need the DCE belongs to ABB Power Oy's
Procontrol PMS
product which is a computer control system for power plants. We have delivered
the
system in hundreds of plants all over the world, selling thousands of Alpha and
Vax computers
at the projects. The customers have been very satisfied with the speed of the
system.
A new version of our product will be delivered during autumn, and we are
planning to
use the OpenVMS version 7.1 as the operating system version.
I myself have been working with VMS systems for 13 years.
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by
vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id KAA27650 for
<[email protected]>; Thu, 29 May 1997 10:58:45 +0200
% Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by
mail.vbo.dec.com (8.7.3/8.7) with ESMTP id LAA21602 for
<[email protected]>; Thu, 29 May 1997 11:12:43 +0200 (MET DST)
% Received: from helu07.ktt.fi (helu07.ktt.fi [192.58.67.10]) by
server21.digital.fr (8.7.5/8.7) with ESMTP id LAA16865 for
<[email protected]>; Thu, 29 May 1997 11:17:14 +0200 (MET DST)
% Received: from csnt02 by helu07.ktt.fi (8.8.3/8.8.3) with SMTP id LAA27285 for
<[email protected]>; Thu, 29 May 1997 11:48:16 +0100 (WET DST)
% Message-ID: <[email protected]>
% Date: Thu, 29 May 1997 12:01:02 +0300
% From: Jari Kulmala <[email protected]>
% Organization: ABB Power Oy
% X-Mailer: Mozilla 2.01Gold (WinNT; I)
% MIME-Version: 1.0
% To: "Simon Cole 830 4084 - Software Partner Engineering
[email protected]" <[email protected]>
% Subject: Re: DCE problem
% References: <[email protected]>
% Content-Type: text/plain; charset=us-ascii
% Content-Transfer-Encoding: 7bit
|
| 2237.5 | Two more mails from Partner | LORDS::COLE | Share and enjoy | Mon Jun 02 1997 05:11 | 112 |
| Date: 29-MAY-1997 10:12:56.54
From: VBORMC::"[email protected]" "Jari Kulmala"
Subj: Re: DCE problem
To: "Simon Cole 830 4084 - Software Partner Engineering
[email protected]" <[email protected]>
CC:
66 records, external message id MAIL$4FA157710005009B.MAI
Attributes: None
>
> Please let me see if I have understood things correctly.
>
> You have a mixed system running V1.2 and v1.4 and it does not work. - TRUE,
but...
>
> An engineer here has run your code with V1.4 on both sides and it does work.
- So the problem must be due to our environment and not to the DCE version
>
> DCE V1.2 has been replaced by later versions and is no longer supported.
- I understand
>
> Please let me know If my understanding of your situation is in error. - Yes,
partly
Here is the full story:
We had a OpenVMS 7.0 Alpha, and DCE 1.3, and everything worked fine. We have a
mixed system in the sense that our VMS cluster contains both OpenVMS 6.2 and
OpenVMS 7.0
computers. However, if you mean with mixed system the mixing of versions between
the client and server side of the DCE/RPC application, this is not the case. DCE
server and
client programs were in the SAME computer, the one that run OpenVMS 7.0.
Then we upgraded to OpenVMS 7.1, and to DCE 1.4, and the application stopped
working.
The application was a server process for our own database product.
Because the application is very large, I prepered a tiny example that revealed
the problem.
All this I did in the OpenVMS 7.1 computer, with DCE 1.4 in it.
In order to be helpful, I also tested the example application in OpenVMS 6.2
with DCE 1.2,
which I happened to be able to access. I also tested the application by running
the server
and client in different versions. You may find the results of these tests from my
original problem submission.
Now, because you can not reproduce the problem, the problem must be caused by
some
component in our OpenVMS 7.1 system. I sent the MAP listing of the linking on
23.5.1997,
from which you can se the exact versions of the run time libraries that the
application
uses.
Also, I heard that a new OpenVMS 7.1 computer will be installed in our office
soon, so
I can test the application also there. Hopefully we together will find a solution
to this problem.
Regards, Jari Kulmala.
Ps. the application for which I need the DCE belongs to ABB Power Oy's
Procontrol PMS
product which is a computer control system for power plants. We have delivered
the
system in hundreds of plants all over the world, selling thousands of Alpha and
Vax computers
at the projects. The customers have been very satisfied with the speed of the
system.
A new version of our product will be delivered during autumn, and we are
planning to
use the OpenVMS version 7.1 as the operating system version.
I myself have been working with VMS systems for 13 years.
Date: 2-JUN-1997 08:49:49.74
From: VBORMC::"[email protected]" "Jari Kulmala"
Subj: Re: DCE problem
To: "Simon Cole 830 4084 - Software Partner Engineering
[email protected]" <[email protected]>
CC:
39 records, external message id MAIL$52BA64BA0005009B.MAI
Attributes: None
Here is some more information about the environment
(our OpenVMS 7.1 AlphaServer 1000 4/200 named PXPS02)
where the DCE problem appears:
1.
When I build programs using MMS, MMS sometimes exits
in error message "%STR-F-FATINTERR, fatal internal error".
This seems to appear only if there are very many dependents
in the dependent lists. Is there a chance that we have
a defective run time library for STR$ -routines? The DECset
version is 12.0.
2.
The DECnet in the computer may not be correctly configured
after upgrade to OpenVMS 7.1. For example the SYS$NODE logical
name does not get defined during the boot, and we have worked
it around by defining the logical name in a command line. Also
the DCE/RPC is unable to use DECnet.
Regards, Jari Kulmala
|
| 2237.6 | From another example. | LORDS::COLE | Share and enjoy | Wed Jun 04 1997 05:46 | 203 |
| Date: 4-JUN-1997 09:29:32.05
From: VBORMC::"[email protected]" "Jari Kulmala"
Subj: Re: DCE problem
To: "Simon Cole 830 4084 - Software Partner Engineering
[email protected]" <[email protected]>
CC:
209 records, external message id MAIL$545245850005009B.MAI
Attributes: New message
Here is some more information to you for inspecting the DCE/RPC problem. Since
you can not reproduce the problem, I inspected the problem in our environment.
I prepared another example that I used. The example now has two RPC routine
definitions:
void t_gets1(
[in] handle_t rpch,
[string,out] char szRet1[9],
[string,out] char szRetStr[200],
[string,out] char szRet2[9]);
void t_gets2(
[in] handle_t rpch,
[string,out] char szRet1[9],
[string,out] char szRetStr[512],
[string,out] char szRet2[9]);
The server returns szRetStr of length 100 for t_gets1(), and szRetStr of length
260 for t_gets2(). The contents of the return string szRetStr is
"AAAAAAAAAABBBBBBBBBB...". The contents of szRet1 and szRet2 are "szRet1V" and
"szRet2V".
The routine t_gets1 works OK but t_gets2 fails, and the client program
displays follows:
%CMA-F-EXCCOPLOS, exception raised; some information lost
-DCERPC-E-FAULTINVALIDBOU, fault invalid bound (dce / rpc)
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
0 FFFFFFFF8080F300 FFFFFFFF8080F300
PTHREAD$RTL 0 000000000003CF14 000000000008EF14
PTHREAD$RTL 0 000000000003CD68 000000000008ED68
T_CLIENT T_IF_CSTUB t_gets2 17043 0000000000001000 0000000000031620
Using TCPIPTRACE, I inspected the packets that flow in the
network and found something that I believe is badly wrong.
Here are some packets that are being transferred after the server returns from
the t_gets1() routine (which works correctly):
$ TCPIPTRACE 138.221.156.12/pack=100/port=local=4346/protocol=tcp/buf=200
--------------------------------------------------------------------------------
TCPIPtrace RCV packet 59 at 4-JUN-1997 09:07:59.78
IP Address Port Seq # Ack #
Source 138.221.156.12 4344 2016896085 2016832125
Destination 138.221.156.12 4346
Packet Length 208
TCP flags PSH ACK
window 4096
Hex Count Ascii
-------- -------- -------- -------- ---- ----------------
0C9CDD8A 5C870680 0000F864 D0000045 0000 E...d......\....
7D6A3678 55643778 FA10F810 | 0C9CDD8A 0010 ........x7dUx6j}
00000110 03020005 | 00005478 00101850 0020 P...xT..........
00000001 00000000 00000002 000000A8 0030 ................
00563174 65527A73 00000008 00000000 0040 ........szRet1V.
41414141 41414141 00000065 00000000 0050 ....e...AAAAAAAA
43434343 42424242 42424242 42424141 0060 AABBBBBBBBBBCCCC
44444444 44444444 44444343 43434343 0070 CCCCCCDDDDDDDDDD
46464646 46464545 45454545 45454545 0080 EEEEEEEEEEFFFFFF
48484747 47474747 47474747 46464646 0090 FFFFGGGGGGGGGGHH
49494949 49494949 48484848 48484848 00A0 HHHHHHHHIIIIIIII
00000000 4A4A4A4A 4A4A4A4A 4A4A4949 00B0 IIJJJJJJJJJJ....
00563274 65527A73 00000008 00000000 00C0 ........szRet2V.
--------------------------------------------------------------------------------
TCPIPtrace XMT packet 60 at 4-JUN-1997 09:07:59.78
IP Address Port Seq # Ack #
Source 138.221.156.12 4346 2016832125 2016896253
Destination 138.221.156.12 4344
Packet Length 40
TCP flags ACK
window 3928
Hex Count Ascii
-------- -------- -------- -------- ---- ----------------
0C9CDD8A 03880680 0000F964 28000045 0000 E..(d...........
FD643778 7D6A3678 F810FA10 | 0C9CDD8A 0010 ........x6j}x7d.
| 0000CE70 580F1050 0020 P..Xp...
The result parameters seem to be transferred in the "packet 59".
Here are some packets that are being transferred after the server returns from
the t_gets2() routine (which reveals the problem):
$ TCPIPTRACE 138.221.156.12/pack=100/port=local=4352/protocol=tcp/buf=200
--------------------------------------------------------------------------------
TCPIPtrace RCV packet 54 at 4-JUN-1997 09:10:11.07
IP Address Port Seq # Ack #
Source 138.221.156.12 4344 2033984085 2033920125
Destination 138.221.156.12 4352
Packet Length 552
TCP flags PSH ACK
window 4096
Hex Count Ascii
-------- -------- -------- -------- ---- ----------------
0C9CDD8A B4810680 00004869 28020045 0000 E..(iH..........
7D283B79 55223C79 0011F810 | 0C9CDD8A 0010 ........y<"Uy;(}
00000110 03020005 | 00006DD9 00101850 0020 P....m..........
00000001 00000000 00000002 00000148 0030 H...............
00563174 65527A73 00000008 00000000 0040 ........szRet1V.
41414141 41414141 00000105 00000000 0050 ........AAAAAAAA
43434343 42424242 42424242 42424141 0060 AABBBBBBBBBBCCCC
44444444 44444444 44444343 43434343 0070 CCCCCCDDDDDDDDDD
46464646 46464545 45454545 45454545 0080 EEEEEEEEEEFFFFFF
48484747 47474747 47474747 46464646 0090 FFFFGGGGGGGGGGHH
49494949 49494949 48484848 48484848 00A0 HHHHHHHHIIIIIIII
4B4B4B4B 4A4A4A4A 4A4A4A4A 4A4A4949 00B0 IIJJJJJJJJJJKKKK
4C4C4C4C 4C4C4C4C 4C4C4B4B 4B4B4B4B 00C0 KKKKKKLLLLLLLLLL
4E4E4E4E 4E4E4D4D 4D4D4D4D 4D4D4D4D 00D0 MMMMMMMMMMNNNNNN
50504F4F 4F4F4F4F 4F4F4F4F 4E4E4E4E 00E0 NNNNOOOOOOOOOOPP
51515151 51515151 50505050 50505050 00F0 PPPPPPPPQQQQQQQQ
53535353 52525252 52525252 52525151 0100 QQRRRRRRRRRRSSSS
54545454 54545454 54545353 53535353 0110 SSSSSSTTTTTTTTTT
00000110 03020005 55555555 55555555 0120 UUUUUUUU........
00000001 00000000 00000002 00000148 0130 H...............
00563174 65527A73 00000008 00000000 0140 ........szRet1V.
41414141 41414141 00000105 00000000 0150 ........AAAAAAAA
43434343 42424242 42424242 42424141 0160 AABBBBBBBBBBCCCC
44444444 44444444 44444343 43434343 0170 CCCCCCDDDDDDDDDD
46464646 46464545 45454545 45454545 0180 EEEEEEEEEEFFFFFF
48484747 47474747 47474747 46464646 0190 FFFFGGGGGGGGGGHH
49494949 49494949 48484848 48484848 01A0 HHHHHHHHIIIIIIII
4B4B4B4B 4A4A4A4A 4A4A4A4A 4A4A4949 01B0 IIJJJJJJJJJJKKKK
4C4C4C4C 4C4C4C4C 4C4C4B4B 4B4B4B4B 01C0 KKKKKKLLLLLLLLLL
4E4E4E4E 4E4E4D4D 4D4D4D4D 4D4D4D4D 01D0 MMMMMMMMMMNNNNNN
50504F4F 4F4F4F4F 4F4F4F4F 4E4E4E4E 01E0 NNNNOOOOOOOOOOPP
51515151 51515151 50505050 50505050 01F0 PPPPPPPPQQQQQQQQ
53535353 52525252 52525252 52525151 0200 QQRRRRRRRRRRSSSS
54545454 54545454 54545353 53535353 0210 SSSSSSTTTTTTTTTT
55555555 55555555 0220 UUUUUUUU
--------------------------------------------------------------------------------
TCPIPtrace XMT packet 55 at 4-JUN-1997 09:10:11.07
IP Address Port Seq # Ack #
Source 138.221.156.12 4352 2033920125 2033984597
Destination 138.221.156.12 4344
Packet Length 40
TCP flags ACK
window 3584
Hex Count Ascii
-------- -------- -------- -------- ---- ----------------
0C9CDD8A B3830680 00004969 28000045 0000 E..(iI..........
55243C79 7D283B79 F8100011 | 0C9CDD8A 0010 ........y;(}y<$U
| 0000BEF2 000E1050 0020 P.......
As can be seen from "packet 54", something has corrupted the transfer of the
result parameters badly.
I hope that you find a person who can diagnose the problem. If you need my new
example program, tell me, and I will send it to you.
Here is once again the configuration of my platform:
- AlphaServer 1000 4/200 running OpenVMS V7.1
- DCE version 1.4
- UCX version V4.1
- the examples were run so that both the client and the server
were in the same node.
Regards, Jari Kulmala.
|
| 2237.7 | UCX show version give what ECO level... | STAR::SWEENEY | | Wed Jun 04 1997 19:33 | 5 |
| In order to duplicate your system can you give the the ECO level for ucx?
Thanks,
Dave
|
| 2237.8 | They have UCX v4.1 | LORDS::COLE | Share and enjoy | Thu Jun 05 1997 05:30 | 27 |
| Date: 5-JUN-1997 09:16:12.03
From: VBORMC::"[email protected]" "Jari Kulmala"
Subj: Re: DCE problem
To: "Simon Cole 830 4084 - Software Partner Engineering
[email protected]" <[email protected]>
CC:
35 records, external message id MAIL$551993150005009B.MAI
Attributes: New message
I think that we have no patches over the UCX 1.4 version.
The command "product show product ucx" displays:
---------------------------------- ----------- ------------
PRODUCT KIT TYPE STATE
----------------------------------- ----------- ------------
DEC AXPVMS UCX V4.1-12 Full LP Available
----------------------------------- ----------- ------------
By the way, the command "UCX SHOW VERSION" displays:
Digital TCP/IP Services for OpenVMS Alpha Version V4.1
on a AlphaServer 1000 4/200 running OpenVMS V7.1
Regards, Jari.
|
| 2237.9 | Please apply latest UCX patch and retest | STAR::SWEENEY | | Thu Jun 05 1997 10:28 | 4 |
|
There are known corruption problems with UCX 4.1. Please install the latest UCX patch for V4.1 and retest.
Dave
|