[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference microw::acmsxp

Title:ACMSxp product questions and comments
Notice:Refer to notes 1 through 11 for conference information
Moderator:DUCAT::ROSCOE
Created:Tue Oct 05 1993
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:282
Total number of notes:1134

249.0. "task adding problem" by OSTV03::K_HORIE () Thu Jan 30 1997 09:46

I'm trying ACMSxp3.0 on Alpha VMS (server) and WNT (client).

When I intend to add a new task to a existing task server, I delete the 
server with the acmsadmin delete command and recreate it with the acmsadmin 
create command.  After the server recreation, sometimes the client can't call 
the server tasks.  The error content is as follow.

	eclass	1
	ecode	98 ( 0x62  %%TPS-F-RPCINVFAIL, RPC invocation failure )

I have found that sometimes the object UUID of the task server was changed by 
the recreation, but the client has the old knowledge of the server object 
UUID in the local copy.  Please see the following.

    on VMS server

	TEPCO> rpccp show server /.:/acmsxp_jit133/hello_hello_task_svr
	
	objects:
	
	  50b903d3-7915-11d0-96a5-08002be4b52c             <--- NEW
	
	binding information:
	
	  <interface id>   cd7782e6-055f-11d0-8582-08002b98af82,0.0
	  <string binding> ncacn_dnet_nsp:62.133[]
	  <string binding> ncacn_ip_tcp:16.161.64.169[]
	
	TEPCO>

    on WNT client

	D:\>rpccp show server /.:/acmsxp_jit133/hello_hello_task_svr
	
	objects:
	
	  b1e3642a-7913-11d0-b573-08002be4b52c             <--- OLD !
	
	binding information:
	
	  <interface id>   cd7782e6-055f-11d0-8582-08002b98af82,0.0
	  <string binding> ncacn_ip_tcp:16.161.64.169
	
	
	D:\>

In such a case, the  rpccp show server -u  command updates the local copy.
It makes the client able to call the server tasks again.

I have some questions about this.

Q1. Is there any method of adding some tasks to a existing task server except 
the server recreation?  The recreation sometimes changes the object UUID, and 
it makes the client unable to call the server tasks.

Q2. Why is the object UUID of the task server sometimes changed by the 
recreation?

Q3. Is there any way to communicate the client with the server even if the 
server object UUID in the client local copy is old?

Q4. We are planning to construct a customer system which consists of about 20 
servers (VMS and WNT) and a few hundred PC clients. (So, I'm trying ACMSxp.) 
We don't want to type the  rpccp show server -u  command on a few hundred PCs 
when some tasks are added to a existing task server.  Any other good ideas 
would be appreciated.


Kouji Horie
T.RTitleUserPersonal
Name		DateLines
249.1CAMINO::VINELEAFThu Jan 30 1997 16:5038
>Q1. Is there any method of adding some tasks to a existing task server except 
>the server recreation?  The recreation sometimes changes the object UUID, and 
>it makes the client unable to call the server tasks.

V3.0 has a new "recreate server command" that helps somewhat, but not with
the object UUID problem. When a task server starts, it checks it's own name
space entry to see if an object UUID exists, and if it does, it reuses it.
If the object uuid does not exist, such as when the server is created and
run for the first time, then a new object UUID is created.

>Q2. Why is the object UUID of the task server sometimes changed by the 
>recreation?

When a server is deleted, so is it's namespace entry. So when the server is
restarted, it doesn't find an already existing object UUID (see above).

>Q3. Is there any way to communicate the client with the server even if the 
>server object UUID in the client local copy is old?

I'm not aware of any way. Perhaps someone else has an idea?

>Q4. We are planning to construct a customer system which consists of about 20 
>servers (VMS and WNT) and a few hundred PC clients. (So, I'm trying ACMSxp.) 
>We don't want to type the  rpccp show server -u  command on a few hundred PCs 
>when some tasks are added to a existing task server.  Any other good ideas 
>would be appreciated.

One thing you could try is to make sure the client and server systems are in
what DCE calls "broadcast range" of one another. When you configure the client
into the cell, if DCE can find the cell with out you having to type in the cell
name, then you are in broadcast range. When this happens, no local cache is
created so you won't have to update the clients using rpccp show server -u. When
the server's object uuid changes, the client picks it up dynamically. As best as
I can tell, broadcast range is close to being on the same TCP/IP subnet, but
I've seen cases where the client didn't think the cell master was in broadcast
range even though the master and the client were on the same piece of thin wire
and on the same subnet!
249.2manual exportingOSTV03::K_HORIEFri Jan 31 1997 08:2317
Vineleaf-san,

>When a task server starts, it checks it's own name space entry to see if an
>object UUID exists, and if it does, it reuses it. If the object uuid does not
>exist, such as when the server is created and run for the first time, then a
>new object UUID is created.

Thanks for your good suggestion!

Today, I deleted a task server and confirmed that its name space entry was 
deleted. After that I recreated the server.  Before starting the server, I 
executed the  rpccp export -o  command with the old object UUID.

When the task server started, the task server used the old object UUID. 
Yeah!

Please advise me if this method is not good.
249.3CAMINO::VINELEAFFri Jan 31 1997 17:0014
Horie-san,

> Please advise me if this method is not good.

I can't see any harm in what you are doing. You are manually populating the
namespace, but there's no real difference between you doing it vs. ACMSxp
doing it. So if it works, continue to use your technique.

We are investigating ways that will not require you to manually export the
binding information. That is, the client will try to effectively do an "rpccp
show server -u" for you. Thank you for bringing this to our attention.

Ken