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

Conference lassie::ucx

Title:DEC TCP/IP Services for OpenVMS
Notice:Note 2-SSB Kits, 3-FT Kits, 4-Patch Info, 7-QAR System
Moderator:ucxaxp.ucx.lkg.dec.com::TIBBERT
Created:Thu Nov 17 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5568
Total number of notes:21492

5490.0. "rsh command doesn't complete." by PFSVAX::WUENSCHELL () Wed May 07 1997 23:51

   Our customer has an application on a VAXeln system that sends an rsh to 
an ALPHAServer 1000 running VMS 6.2-1h3 and UCX 4.1 ECO 4.  The rsh is 
supposed to kick off a command file on the Alpha.  The command sent to 
the Alpha is rsh @lee.com.  The command file will run succesfully only 
about one time out of 10.

By inserting REPLY's in lee.com, we see that the command file will 
sometimes execute a few lines, sometimes none at all, sometimes completely.

An IRIS trace shows that the TCP connection to the Alpha is succesfully 
established, and that the correct string is sent to the Alpha.  The Alpha 
ACKs that packet and then the VAXeln system sends a TCP packet to the Alpha
with the reset bit set in the packet header.  The Alpha replies with a 
reset packet and the TCP connection is dropped.  It seems that this is the 
point at which either UCX$RSHD_STARTUP.COM or LEE.COM terminates.

It would seem logical that once the Alpha has received the packet with the
rsh string and ACK'd it, it would go and execute the command regardless of 
the state of the circuit.  If the VAXeln system sends an rsh to an HP or
PC to initiate a similar command string, the command executes completely.

We have tried various TCP configuration settings under UCX, including 
raising or lowering the SEND and RECEIVE quotas, turning DELAY_ACK off and 
on, revising the checksuma and PUSH setting, to no effect.

Can we configure UCX to make this work?

I can post the LAN trace if that would help.
T.RTitleUserPersonal
Name
DateLines
5490.1IPMT timeLADDIE::TIBBERTLee Tibbert, DTN 226-6115Thu May 08 1997 16:1040
The fact that .0 starts with "our customer" is a good
clue that you should file an IPMT.

This is almost certainly a customer configuration issue.
One would need to see the contents of the file lee.com
Such things take time. IPMTs give a 'charge number' for
the time invested.

That said...

I am not the Rcommands maintainer, but I did just
fix a series of bugs in the Rcommands.  I know of
nothing such as you report. This would be a 
new situation.

RSH is used in the build of UCX for Alpha, so we
are pretty sensitive to it being broken ;-)

Two things that you can check:

	1) You could check that the 
	   sys$sysdevice:[ucx$rsh]ucx$rsh(d?)_startup.com is the
	   same as the one in the UCX 4.1 kit.  If this was a new, clean
	   installation, this is probably so.  If UCX was upgraded
	   from a pre-existing version, it is possible that an old
	   file was left around. Now, I know of no changes in this
	   file from UCX X.X to 4.1, but there may have been. 


	2) (John G. please keep me on the straight and narrow here).

	    For complex reasons, some of the Rcommands do not like
	    keyboard input/activity while they are processing. That
	    is typeahead at the keyboard can mess-up (technical term)
	    the command.  I'm not sure if RSH is one of these.

I hope this helps,

Lee
5490.2rsh may not support starting com filesPFSVAX::WUENSCHELLThu May 08 1997 17:406
    Thanks for the reply.  I will IPMT the case.  
    I was told by a support center engineer that an rsh should not be used
    to start a command procedure, that rexec should be used.
    However if I do a help rsh on my VAX it specifically says it can be
    used to start scripts or command procedures.
    Hopefully an IPMT will clarify things.
5490.3TLE::REAGANAll of this chaos makes perfect senseFri May 09 1997 10:288
    Huh?
    
    >I was told by a support center engineer that an rsh should not be used
    >to start a command procedure, that rexec should be used.
    
    Whomever said that doesn't know what they are talking about.
    
    				-John
5490.4Looks like RSHD_STARTUP did change.PFSVAX::WUENSCHELLFri May 09 1997 13:5864
    re .3.  Actually I upgraded from UCX 3.3 to 4.1 on my Alpha just to
    play around with this problem.  It seems that the UCX$RSHD_STARTUP.COM
    file did change from 3.3 to 4.1.  The new file is
    
    $ !  UCX$RSHD_STARTUP.COM
    $ !
    $ !  Copyright (c) Digital Equipment Corporation, 1990, 1992, 1996
    $ !  All Rights Reserved.  Unpublished rights reserved
    $ !  under the copyright laws of the United States.
    $ !  
    $ !  The software contained on this media is proprietary
    $ !  to and embodies the confidential technology of 
    $ !  Digital Equipment Corporation.  Possession, use,
    $ !  duplication or dissemination of the software and
    $ !  media is authorized only pursuant to a valid written
    $ !  license from Digital Equipment Corporation.
    $ !
    $ !  RESTRICTED RIGHTS LEGEND   Use, duplication, or 
    $ !  disclosure by the U.S. Government is subject to
    $ !  restrictions as set forth in Subparagraph (c)(1)(ii)
    $ !  of DFARS 252.227-7013, or in FAR 52.227-19, as
    $ !  applicable.
    $ !***************************************************************
    $ !
    $ ! Parse out the BG devices for error and output, and the command
    string
    $ !
    $ set noverify
    $ on error then goto exit
    $ sys_net = f$trnlnm ("SYS$NET")
    $ s = f$locate ("$" , sys_net) + 1
    $ l = f$length (sys_net)
    $ z_net = f$extract (0, s-1 , sys_net)
    $ s_command = f$extract (s, l-s , sys_net)
    $ z_net = f$extract (0, s-1 , sys_net)
    $ l1 = f$length (z_net)
    $ s1 = f$locate (":" , z_net) + 1
    $ ss_bg1 = f$extract (0, s1 , z_net)
    $ ss_bg2 = f$extract (s1, l1 , z_net)
    $ if ("''ss_bg2'" .eqs. "") then ss_bg2 = ss_bg1
    $ !
    $ !Now:
    $ ! ss_bg1 has the output device,
    $ ! ss_bg2 has the error device, and
    $ ! s_command has the command.
    $ ! Allocate the devices so they stay around, define the output and
    execute
    $ ! the command.  Wait a bit so output buffer is flushed.  
    $ !
    $ alloc/nolog 'ss_bg1'
    $ alloc/nolog 'ss_bg2'
    $ if ss_bg1 .nes. ss_bg2 then define sys$error 'ss_bg2'
    $ define sys$output 'ss_bg1'
    $ write sys$output ""
    $ 's_command'
    $ write sys$output ""
    $exit:
    $ exit $status
    $ 
    
    The old file had a $ WAIT 00:00:01  just before the $EXIT:
    I wish I had saved it before upgrading.
    Do you think this might make a difference?
    
5490.5rsh does not complete for me tooVIRGIN::BASSITue May 13 1997 05:0324
 Hi all,

 one customer (check Nice call #5500) has the same RSH pb highlighted under .0 
 using the following configuration:


                 RSH-clnt                         RSH-srv

        - OVMS AXP V6.2-1H3                - DECBrouter90 2TA
        - UCX V4.1-ECO4                    - Firmware 10.3.17


   *** WARNING:  first UCX installation ;-(
  
 
 TCP traces attached to #5500 report the same RSH behaviour described under .0

 More informations from UCX-Engineering ?  Should i IPMT ?
 Did you already IPMT ?  If yes, which CFS nr ?

 Many thanks in advance.

    gianbattista 760-2717