From the SOLVE Resource Monitor--if one issues the L command against more than one resource
and hits enter--it will show the Transient Log for the first resource. But after a short period
(15+ seconds) with no intervention it will automatically jump to the Transient Log
of the next resource in the queue.
It will keep jumping until it hits the last resource in the queue where it will then stop.
Hitting PF3 will then start showing the Transient Logs in the reverse order.
Release : 11.9
Component : CA SOLVE:Operations Automation for z/OS
L2 Support explained such behavior:
This is actually working as designed. When a user enters in multiple line
commands against multiple resources, these are all queued to be exe-
cuted, with the philosophy that the user will execute the first com-
mand, then possibly PF03 (to terminate existing window) to go
to the next command and so on, until the last command has
As an example, enter the 'L' command against multiple resources, and just
PF03 through the Resource Transient Log list until last one is hit--it will
take you back to Resource Monitor.
Now, under the covers, the Resource Monitor code has timeout facilities on
these line commands to capture any commands that might not execute in
a specific time frame (20 seconds). This is done purposely to capture any
command that might have stalled, as the product wants to give control
back to the user's window.
When this happens, the user will see the RMCALL24 message. So, in the
case where a user enters in multiple 'L' commands, and then just sat on
a specific window, underneath the covers the window was getting the
RMCALL24 message, but when it woke up, it just executed the next
command in the stack ('L').
The user never sees the RMCALL24 because there is always a new
window to display. Here is the explanation of RMCALL24:
RMCALL24 - '&P1' COMMAND HAS NOT RESPONDED WITHIN TIME LIMIT
The command processor, which is executing the command identified by
P1 , has not received any response from the command within 20 sec-
onds and has issued this message and unlocked the keyboard so
that subsequent commands may be issued.
This may indicate that the command is still in progress or may have end-
ed unsuccessfully. Check the log for any errors.
So, there is nothing wrong with this behavior--it is working as designed.