Windows is unable to start VMS EXEcutable

[Arch_Muthiah]

Steven,

Yes it is useless meaning less message only. As you all said, this won't be cluster related issue, now I am looking into the code. As the processing is done using many threads, this message is there in tooo many places.

I have the similar environment as the customer who face this error, the only difference is that mine is individual node, but the customer said has configured their machine as single cluster node.

It works fine on my environment.

Archunan

[Volker Halle]

Archunan,

your trace does not show the complete TCP connection establishment and data exchange, something is missing at the beginning. The trace starts in the middle of an existing connection. A TCP connection starts with a message having the SYN bit set and a reply with SYN and ACK set. This is missing in your trace. Your trace only covers 510 milliseconds of TCP traffic between 2 hosts on 3-AUG-2006. The .LOG file you've shown is from 26-APR-2006. Please provide the .LOG file from the same time as the failing test.

Please verify the IP adresses shown, to confirm, that they are indeed from your VMS system and your Windows system involved in this test.

TCPTRACE was running on your VMS system to capture the failure, right ? If the VMS system would not have had quorum, the VMS system and TCPTRACE would have hung and not produced anything.


TCPTRACE command was taken from the working env.


Are you saying that the trace you've taken shows a successful TCP message exchange and a successful start of the program on VMS ? Next time, please ask the customer to start TCPTRACE, wait 10 seconds, start Windows program, wait until error message shows up and then stop TCPTRACE. By default, TCPTRACE will automatically stop after capturing 10 packets. You might need to run it with /PACKETS=100 and then CTRL-C out of it, once the error has been shown on the Windows GUI.

If it works on your standalone node, just temporarily re-configure that node with VAXCLUSTER=2, VOTES=1 and EXPECTED_VOTES=1, reboot and re-test. That should be easy.

Also consider to take a TCPTRACE in your working environment first, then you have something to compare the failing case with.

Volker.

[Arch_Muthiah]

Thanks volker for your long posting.

As per your suggestion, I asked the customer to change the cluster para and test the appl. once I get, I will post.

TCPTRACE and LOg file were taken the customer env only, the LOG file date is difft, but all the log file contains the same contents only.

Also I found that there is no problem in communication (wind to vms) as VMS application had been started by the COM procedure. But VMS application got delayed and windows errored out with "Unable to start the VMS' xxxx.EXE program" - it is windows side appl message. I have no idea about windows side source code.

I am still wondering why this application errored out only in single node cluster env!!!, while it runs fine in standalone system and two node cluster env?

Any known restrictions/issues running the application in single node cluster env?.
Or any two NIC (incomming and outgoing) config in wind or VMS?, I will have to ask about this to the customer.

Still hoping to get the suggestion from our Ian, volker, Uwe, Bob, Karl, Stewen, John, Wim, or especially our Cluster Guide - Jan.

Thanks
Archunan

[Steven Schweda]

> Any known restrictions/issues running the
> application in single node cluster env?.

Only if your application is particularly
weird. My primary system is an XP1000 which
is normally the only system in its cluster,
although other systems come and go from time
to time. I've never seen a normal
application which cared whether it was
running on a cluster member.

+--------------------------------------------------------+---------+
| SYSTEMS | MEMBERS |
+--------+--------------------------------+--------------+---------+
| NODE | HW_TYPE | SOFTWARE | STATUS |
+--------+--------------------------------+--------------+---------+
| ALP | COMPAQ Professional Workstatio | VMS V7.3-2 | MEMBER |
| ALP2 | COMPAQ Professional Workstatio | VMS V8.2 | BRK_NON |
| WUSS | VAXstation 3100/GPX | VMS V7.3 | BRK_NON |
| GIMP | VAX 4000-200 | VMS V7.3 | BRK_NON |
+--------+--------------------------------+--------------+---------+

[Wim Van den Wyngaert]

I would concentrate on tcpip config.

Check the file tcpip$etc:sysconfigtab.dat on a working and non-working system. May be a timeout is configured too low.

BTW : avoid giving more than 7 points without having the solution for your problem. This question has a "bunny" but no solution (yet).

Wim

[Wim Van den Wyngaert]

And check accounting for process termination status, operator log file for messages that might have been given by the application or tcpip and audit log file for violations.

Wim

[Phil.Howell]

I don't think cluster parameters would have anything to do with the problem.
What I would do...

Find the startup procedure that produces the log file and remove the set verify.

Add the line
$ set watch /class=major file
to the startup procedure

This should produce more detailed logs for further diagnosis
Phil

[Volker Halle]

Archunan,


As per your suggestion, I asked the customer to change the cluster para and test the appl. once I get, I will post.


I suggested that you temporarily change YOUR test system to become a single node cluster, so that we can easily rule out the 'application does not work on single node cluster' theory.

Volker.

[Arch_Muthiah]

Wim,

Thanks for the info about the ITRC pointing method. But I usually respect our members for their valuable time to read/understand my lenthiest questions described with my poor english knowledge. And I saw responses also composed in a big paras. So I feel I am right giving the points. Especially Volker, Jan and Steven spending their time to compose a big responses with broad range of informations, I really learn lot from their postings.

Anyway I followed your suggestions and not given 10 points this time.

Phil: I will try your sugestion today.

Wim: VMS application keeps trying to continue the processing, so the VMS application did not timedout. The timeout message is from windows application only. I even tested increasing the timeout env parameter in windows side as windows appl uses this para. Anyway I try your suggestion too.

Volker: This problem is in the customer's testing system only. So they can change the system to standalone system. So no problem.

Thanks
Archunan

[Volker Halle]

Archunan,


VMS application keeps trying to continue the processing, so the VMS application did not timedout. The timeout message is from windows application only.


If the VMS side continues to run and the Windows side reports a timeout, then I could only think of 2 scenarios:

- either the VMS side did not correctly indicate that it's working, before closing the TCP connection

- the Windows side expects additional information from the VMS side, which could only be through another TCP connection.

Maybe you need to trace ALL TCPIP traffic between the 2 nodes and you should also consider to take a TCPIP trace of a working configuration. Then you may be able to spot the difference and find out where it's going wrong and what is missing.

Volker.