Community
Participate
Working Groups
Build Identifier: This has been reported by an RDz 7.6.1 customer for POC: In the Remote Shell view: a) In the Command field, if you run a long running command (such as find), there is no response from the view for a couple of seconds (at least the one I tried), since you are not sure what it going on during that time, you enter another command. The command field is not greyed out to let you know it is processing the previous command you had typed and the new command is not accepted either. According to the test I did, only the first time processing of that command may result to this behaviour and for any subsequent attempt the respond is instantaneous. b) When you are running a long running command (such as find / rsecomm.log -print) you have no way of cancelling the command. This has been verified. c) Some commands do not work as expected, one example is the ps command: when you run the command shows the following error: ps: FSUMA902 can't access your terminal d) The view disappears without any warning. I cannot reproduce this and have asked the customer to provide the .log file the next time that happens. Reproducible: Always Steps to Reproduce: 1. Start RDz 7.6.1 2. Connect to a remote system and open the Remote Shell view. 3. Follow the information in details to reproduce the problem
a) I haven't yet reproduced the case where it takes a couple of seconds to see any response although I haven't yet tried on z/os. The RSE shell does not support the ability to know whether something is running in the shell at some time so it can't grey out the command field while the shell is active - further, some commands are interactive (i.e. require user input). My question is whether the complaint here is about the greying out of the field or the delay experienced at the start? b) Over dstore, without rseterm, users can't cancel a specific command from the RSE shell. The user can still cancel the shell or via the process subsystem (if it's in the product) he/she may cancel the command from there. c) Because there is no terminal when rseterm is absent, commands like "ps" can't run in the RSE shell on z/os.
Dave, a) The problem is the delay factor. In this case, because of the delay, they think nothing has happened. They also see the prompt and type in another command without anything happening. I noticed that the field was not greyed out and it would have helped the customer to know he could not enter any other commands because the one that was entered was being processed. b)If that is the case, it should be documented in the product docs. I will update the work item in RTC and notify the doc owners of it. c) Again, ths should be documented because the user expects it to work the same way as using it in rseterm.
(In reply to comment #2) > Dave, > > a) The problem is the delay factor. In this case, because of the delay, they > think nothing has happened. They also see the prompt and type in another > command without anything happening. I noticed that the field was not greyed out > and it would have helped the customer to know he could not enter any other > commands because the one that was entered was being processed. > Does this delay occur for any shell command or just long running commands?
The delay is for long running commands and as far as my experience only the first time. Any subsequent time, there is no delay.
Is there any work than can be done to resolve the delay issue (with prompt still active)? If so, how much effort would be involved with that? Could it be a temp fix?
Dave, for b) and c) is it possible to provide rseterm? If so how much effort would be assoicated with it?
(In reply to comment #4) > The delay is for long running commands and as far as my experience only the > first time. Any subsequent time, there is no delay. So the delay does not happen when instantiating a shell but rather after the first command has been run. Is there any delay if the first command is not long running?
(In reply to comment #5) > Is there any work than can be done to resolve the delay issue (with prompt > still active)? If so, how much effort would be involved with that? Could it be > a temp fix? I haven't reproduced the bug yet (perhaps it occurs only on zos or via RDz but I'm not sure). Until I know what's causing the delay, I'm not sure what would be required to fix it.
(In reply to comment #6) > Dave, for b) and c) is it possible to provide rseterm? If so how much effort > would be assoicated with it? The problem with rseterm is that its zos implementation is currently unsupported. We think that a better solution for all these shell issues would be to bring in the SSH Terminal support.
It would be very easy to reproduce the delay. It does not occur when it is not a long running command. As for the SSH terminal support, is this something that can be done in the near future? These requests are with respect to POC and what they are looking for is if we can provide either a short term solution or have some information about the long term solution if that is at all possible.
(In reply to comment #10) > It would be very easy to reproduce the delay. Using base RSE, I have not been able to reproduce this. I may need to use RDz in order to hit this since it have a slightly different server model which might account for delays. Are you able to reproduce this via an Unix connection to the zos machine? > As for the SSH terminal support, is this something that > can be done in the near future? These requests are with respect to POC and what > they are looking for is if we can provide either a short term solution or have > some information about the long term solution if that is at all possible. Ankit and I have brought the SSH terminal support into the discussion with Pavan and Venkat. This could probably be done in the v8 release but it couldn't be taken back to 7.6.
Dave, I tried it from within RDz 7.6.1 and was connected to CTFMVS08.rtp.raleigh.ibm.com. If by "trying using Unix connection" you mean to do a rlogin (through PUTTY) to that system, I did. I did not see a delay but you do not get a prompt while the command is running so there is no confusion there. They see the prompt while the command is about to run and they can enter a command even though nothing happens when they do.
(In reply to comment #12) > Dave, I tried it from within RDz 7.6.1 and was connected to > CTFMVS08.rtp.raleigh.ibm.com. If by "trying using Unix connection" you mean to > do a rlogin (through PUTTY) to that system, I did. I did not see a delay but > you do not get a prompt while the command is running so there is no confusion > there. They see the prompt while the command is about to run and they can enter > a command even though nothing happens when they do. By Unix connection, I mean create an RSE "Unix" connection (instead of a zos connection). You should be able to connect to it either manually or via REXEC if you know the server install location.
I do not know how what you mean by creating an RSE unix connection. I did an rlogin using putty to that system and it a unix terminal and could run the commands from a unix shell. The long running commands did not provide a prompt while it was still running and I did not see any delay.
