Workstation/Client Tuxedo Config.
Melissa Jo Pellegrin
I am trying to locate some documentation on configuring a Windows NT
Workstation/Client to connect to a UNIX Tuxedo Server. I have the
documentation from BEA and have Tuxedo up and running successfully on the
UNIX side. However, the Windows NT client does not seem to be making the
connection properly. I have supplied the correct WSN address, but Tuxedo
on the Windows NT side is still looking for the server code.
Any information would be greatly appreciated!
Thanks!
carew
On 2 Dec 1997 15:35:00 GMT, silo!mpel...@uunet.uu.net (Melissa Jo
Pellegrin) wrote:
You need to ensure that the environment variables are set up
correctly. Tuxedo needs TUXDIR and WSENVFILE set in the
settings/system/environment area. The WSENVFILE should be the path of
the file where your wsnaddr is defined and also where such things as
the ulog prefix and the application name, if you are using one.
>
>
Jack Beatty
What do you mean by "still looking for the server code"?
Have you checked the ULOG on the client machine to see what message you are
getting?
Additionally, how are you specifying the WSN. There is an environment
variable WSNADDR that you can set, or a better way I've found, is to use the
WSENVFILE environment variable. This specifies a text file name that you can
then type in all the variables (WSNADDR, ULOGPFX, etc).
Finally, are you sure that you have a Windows NT version of the /ws client
DLL (wtuxws.dll?). The windows 3.1 version does not work with a 32 bit
TCP/IP stack.
HTH,
Jack
Rick Robinson
In article <661g24$9...@svlinweb.beasys.com>,
silo!mpel...@uunet.uu.net (Melissa Jo Pellegrin) wrote:
>
>
> I am trying to locate some documentation on configuring a Windows NT
> Workstation/Client to connect to a UNIX Tuxedo Server. I have the
> documentation from BEA and have Tuxedo up and running successfully on the
> UNIX side. However, the Windows NT client does not seem to be making the
> connection properly. I have supplied the correct WSN address, but Tuxedo
> on the Windows NT side is still looking for the server code.
>
> Any information would be greatly appreciated!
>
> Thanks!
Not a whole lot of configuration must be done on your client
workstation...
Some clarification questions:
- What versions are you running (of Tux, Unix, NT)?
- How is it you know this problem is occurring? Are you getting (and
logging) error messages? What error(s) are you getting?
(Errors returned in variable
tperrno - use function tpstrerror() to get decode of tperrno).
- Are you positive that the address specified for your WSL server on the
Unix box matches the WSNADDR environment variable you specified
on your NT box?
- Is the environment variable TUXDIR correctly set in your NT
environment? It should refer to the base install directory for your
Tuxedo software.
- Is the Tuxedo bin directory in your NT path? If not, add %TUXDIR%\bin
to your NT path.
Best of luck.
--
regards,
Rick
Melissa Jo Pellegrin
Jack Beatty (climb5...@erols.com) wrote:
: What do you mean by "still looking for the server code"?
What I meant is that the client acts as if the server is configured on the same system as the client. It does
not recognize the fact that the server is located outside of its local domain. Does this make sense or have I
made the water
muddier? :)
: Have you checked the ULOG on the client machine to see what message you are
: getting?
From what I can tell, no information is being passed back to the ULOG. However,
my co-worker does receive a message stating that TUXCONFIG is not found. On
the UNIX system, that tells me that the system is trying to point to the directory where the UBB is stored. In
this scenario, it is located on a UNIX system.
: Additionally, how are you specifying the WSN. There is an environment
: variable WSNADDR that you can set, or a better way I've found, is to use the
: WSENVFILE environment variable. This specifies a text file name that you can
: then type in all the variables (WSNADDR, ULOGPFX, etc).
Perhaps, this is what we need to do as well. The WSNADDR is set in the Windows
NT environment as well as TUXCONFIG, but Tuxedo will not recognize it. We have
run the "set" command to make sure that all env variables are displaying and
both variables show up.
: Finally, are you sure that you have a Windows NT version of the /ws client
: DLL (wtuxws.dll?). The windows 3.1 version does not work with a 32 bit
: TCP/IP stack.
Unfortunately, I personally cannot verify that due to the fact that the system
administrators installed the code and I do not have access to the actual
installation media. However, I do remember seeing wtuxws.dll in his
C:\tuxedo\bin directory. Therefore, I presume that it is the correct version.
I will have him double check on that issue.
Thanks for the help! BTW, do you have any suggestions on where there is
better documented information on setting up the workstation/client?
Melissa Jo Pellegrin
From: us...@carew.u-net.com (carew)
> You need to ensure that the environment variables are set up
> correctly. Tuxedo needs TUXDIR and WSENVFILE set in the
> settings/system/environment area. The WSENVFILE should be the path of
> the file where your wsnaddr is defined and also where such things as
> the ulog prefix and the application name, if you are using one.
For the sake of clarification and not to sound too stupid, are these
settings supposed to be defined in the system environment or in the user
environment? Moreover, does Tuxedo differentiate between the system's or
user's environment?
-- Melissa
Rick Robinson
Melissa Pellegrin wrote:
>
> In regard to your questions:
>
> 1. Running Tuxedo 6.2 on HP Unix
> Tuxedo 6.2 on Windows NT 4.0
>
> 2. I know that the problem is occurring in that we receive error
> messages in the ULOG stating that it cannot find TUXCONF. This
> tells me that Tuxedo thinks that the client system has the Tuxedo
> Server running on it as well.
>
> 3. I have confirmed several times that the WSN Address variables
> match.
>
> 4. The Tuxdir is set correctly and it shows up in when doing "set".
> However, Tuxedo is not seeing this variable either.
>
> 5. The bin directory has been specified in the NT Path statement.
>
> Any further suggestions are greatly appreciated!
I read some more of the stuff in the discussion group...I think I know
what your issue is...
When you built your NT client, did you use the buildclient utility? And
did you use the -w option to create your client as a /WS client? If
not, then your client will be attempting to attach to a local Tuxedo
server environment via native IPC resources (and you'll get those
messages which are looking for a TUXCONFIG variable, etc.).
Hope this helps.
Side note: Our BEA rep. recommended that we not stay on Tuxedo 6.2 for
various reasons...recommend you upgrade to 6.3 given your environment.
--
regards,
Rick
Jack Beatty
Melissa Jo Pellegrin wrote:
> Jack Beatty (climb5...@erols.com) wrote:
> : What do you mean by "still looking for the server code"?
> What I meant is that the client acts as if the server is configured on
the same system as the client. It does
> not recognize the fact that the server is located outside of its local
domain. Does this make sense or have I made the water muddier? :)
Make sure that when you compile the client (buildclient) thatyou use the -w
switch. This tells that linker to link
the /ws objects and not the regular tux objects. This sounds like why the
client thinks its still on the same
machine. You can have clients on the same machine, you just don't use the
-w option.
As for the documentation, I can't help you there. Welcome to the world of
Tuxedo, the doco stinks.
Scott Hemming
Did you run buildcleint with -w (meaning use the network stub, not the share
memory libs)? Does this Tuxedo configuration work with other /WS clients or
is your's the first attempt? You could try to telnet to the wsl address and
port and if telnet hangs, then at least you know the listener is running
where you think it is.
Rolin Nelson
Mellisa,
If you are still having problems, verify the following:
1) UNIX machine is reachable from NT
Run the 'ping' command from the NT command prompt with the network
address of UNIX machine. ie. >ping 100.100.10.5. If it is not reachable
then your NT box needs to be in a network reachable to the Unix box.
2) TUXDIR and PATH is set correctly
TUXDIR must be set. PATH must include TUXDIR\bin.
3) WSNADDR is set correctly
Verify that WSNADDR is set either in User or System variables and that it
matches the WSNADDR in your WSL server on the UNIX box.
4) WSC is built correctly
Verify that your NT client was built with the -w option (ie. buildclient
-w -f simplc.c -o simpcl)
5) Set ULOGPFX on NT to locate client errors
Set ULOGPFX so that client errors can easily be found. (ie.
ULOGPFX=C:\%TUXDIR%\logs\ULOG). Now, when your client fails, view log to
find exact error. This is the place to look for client errors, not the ULOG
on the UNIX side.
If you've verified the above and you client still fails, then you need to
verify you application on the UNIX side.
Rolin