There is a possible race condition in SCP command processing.
I say "possible" since the manner in which it is currently behaving might be correct. Further research is required to determine whether the current behavior is correct or not.
When multiple SCP guest commands are issued in rapid succession (by leveraging the now fixed 'cmdsep' feature), it is possible for one or more subsequent commands to be skipped/missed (not processed) while the current command is being processed.
The following log file extract illustrates this behavior:
The above .rc file was used to trigger the behavior. The guest O/S used was z/VM 6.3, but other modern operating systems (such as z/OS) behave similarly.
The test was performed on a Windows 7 x64 host running commit 424ba73e3fad27e15833bb59e2d9289a7ca6b009 of Hyperion, dated Nov 11, 2017 (i.e. the cmdsep fix).
There is a possible race condition in SCP command processing.
I say "possible" since the manner in which it is currently behaving might be correct. Further research is required to determine whether the current behavior is correct or not.
When multiple SCP guest commands are issued in rapid succession (by leveraging the now fixed 'cmdsep' feature), it is possible for one or more subsequent commands to be skipped/missed (not processed) while the current command is being processed.
The following log file extract illustrates this behavior:
The above .rc file was used to trigger the behavior. The guest O/S used was z/VM 6.3, but other modern operating systems (such as z/OS) behave similarly.
The test was performed on a Windows 7 x64 host running commit 424ba73e3fad27e15833bb59e2d9289a7ca6b009 of Hyperion, dated Nov 11, 2017 (i.e. the cmdsep fix).
As you can see, several commands were skipped/missed (not processed by the guest).
As I explained, this may be correct behavior. I don't know. More research is needed.
I am simply creating this GitHub "Issue" for the benefit of others and so I don't forget to look into the "problem" in case it actually is a problem.