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

Conference decwet::windows-nt

Title:	Windows NT
Notice:	See note 15.0 for HCL location
Moderator:	TARKIN::LIN.com::FOLEY

Created:	Thu Oct 31 1991
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6086
Total number of notes:	31449

5832.0. "WNT 3.51 and Stress for V4.0 error" by CARECL::CASTIEN (Hans Castien 889-9225) Sun Mar 23 1997 23:44

    
    Hi,
    
    In our repair site in JGO, we use ntstress fora final verification on
    NT only systems (Alpha and Intel)
    
    Our ntstress server is just upgraded to NT V4.0 and I also the latest
    version of stress.
    
    Our V3.51 systems (Rawhide and Multia) will however not run ntstress
    properly any longer.The saystems complain about MSCTL.DLL not to be
    found in the path.
    
    Howe can I resolve this? Do I have to use the old version of ntstress
    also to test the V4.0 nodes, or can I use a V4.0 copy of the DLL on the
    V3.51 systems?
    
    Hans

T.R Title User Personal
Name Date Lines

5832.1 << Played with any slime lately? >> POBOXA::COMMO I'll find no bug before its time! Wed Mar 26 1997 05:41 28

T.R	Title	User	Personal Name	Date	Lines
5832.1	<< Played with any slime lately? >>	POBOXA::COMMO	I'll find no bug before its time!	`Wed Mar 26 1997 05:41`	28
	Hi Hans, I'll take a gather at answering this. Of course right up front I will reserve the right from someone from ZSO to bat me about the ears where I have strayed from the truth (somedays that's seems to occur on about the second step ;.!) Yes, moving MSCTL.DLL to the appropriate path might solve the problem, or worse appear to solve the problem. Could you ever trust an "error" on an NT3.51 machine that is running NT4.0 stress bits? I would be very afraid to. The rigorously correct way to do it would be to have two servers, on separate subnets(!), each with a lanman name of NTSTRESS. Have one setup for NT3.51 and the other setup for NT4.0. Connect the clients to the appropriate network. A pain? Yes! I did slime past the problem once by having a machine named \\ntstress, but with a different TCP/IP name. On the client I I created a local HOST file that had an entry for "ntstress" that pointed to the correct machine. Since there was no lanman machine named \\ntstress on the same since of the router as the client the client used TCP/IP for name resolution, looked in its own host file and was off and running. The implication of this experiment (which was out of necessity) points to a possible solution to your case. Good luck. -norm

Hi Hans,

I'll take a gather at answering this.  Of course right up front I will 
reserve the right from someone from ZSO to bat me about the ears where 
I have strayed from the  truth (somedays that's seems to occur on about 
the second step ;.!)

Yes, moving MSCTL.DLL to the appropriate path might solve the problem, or
worse *appear* to solve the problem.  Could you ever trust an "error" on
an NT3.51 machine that is running NT4.0 stress bits?  I would be very 
afraid to.

The rigorously correct way to do it would be to have two servers, on 
separate subnets(!), each with a lanman name of NTSTRESS.  Have one
setup for NT3.51 and the other setup for NT4.0.  Connect the clients to
the appropriate network.

A pain? Yes!  I did *slime* past the problem once by having a machine 
named \\ntstress, but with a different TCP/IP name.  On the client I 
I created a local HOST file that had an entry for "ntstress" that pointed
to the correct machine.  Since there was no lanman machine named \\ntstress
on the same since of the router as the client the client used TCP/IP for
name resolution, looked in its own host file and was off and running.

The implication of this experiment (which was out of necessity) points to
a possible solution to your case.  Good luck.

-norm