Unfortunately, it has changed. The CRI captures the responses, even if the commands are CP commands, on the local node, and used to do so for commands to other nodes. Now its behavior, when sending a command to a different node, mimics that of the FOR command, regardless of how the command is actually executed. There is an immediate rc=0 with no message and the real response is returned as asynchronous messages from the target node.
The CRI is supposed to act differently than a simple "SMSG RSCS CMD ...". It is, by its very name, different. CRI stands for Command Response Interface. It WAS a programming interface. It was a way out of the screen scraping morass. It identified the command that caused the response and indicated when the response was complete. Now, it does not, except for commands to the local node. If it is behaving correctly now, perhaps its name ought to be changed to LCRI (L for Local). If all I wanted was to have the messages displayed on the console, I wouldn't use a programming interface to issue the commands in the first place. Screen scraping, while currently effective is ugly as well as being unreliable. First, it is necessary to capture CPCONIO message traffic. Then it is required that the real command be followed with something recognizable so that it is known when the response is complete. Non-related message traffic must be filtered out, too. It has been my experience that all of the systems in our NJE network regard GARBAGE as an invalid command and include that word in a one-line response. I can use that as my end-of-command sentinel. If, for some reason, one or more of the systems implements a GARBAGE command or includes that word, all in caps., in a legitimate response, I am in trouble. I may even be in trouble if a userid GARBAGE is ever created on one of the systems. You say that it should not have changed. I could not agree with you more. It should not have changed. It did work for both the local node and remote nodes in VM/XA and VM/ESA. It changed at some time - probably when we were given a new version. Unfortunately, the use of the code had apparently ebbed and I did not catch it at the time of the change; nobody reported a problem. Now, we have a real need to capture the responses from JES queries, and we must scrape the screen to get them. One of the responses is variable in length and usually in the 50-100 lines range, so an end-of-reply indicator really is imperative. That is why PMR 15882,49R,000 was opened on 10/16. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Les Geer (607-429-3580) > Sent: Thursday, November 12, 2009 12:29 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: SFS and CP Question > > >No, I mean that when sending a command to a different node, the RSCS > >CRI acts exactly like the FOR command. Instead of capturing the > >response and returning it with the CRI headings, it gives > the user an > >immediate rc=0 and allows the responses to be returned as > asynchronous > >messages from the other node. In other words, using CRI to send a > >command to another node is a useless exercise. > > > >Try using CRI to send a very simple command to another node, > something > >like CP QUERY TIME if the other node is VM or $DA if z/OS. Then try > >doing the equivalent command on the local node and you will > see the difference. > >On the local node, the responses are returned dressed in > their full CRI > >regalia, instead of being asynchronous messages.=20 > > RSCS does not use underlying CP facilities when sending a > command from one node to another. Instead, NJE protocols are > used for the command and response. The command complete from > RSCS is for the MSG/CMD command, not whatever is bundled > within MSG or CMD. The only time RSCS would issue CP FOR (or > CP FORWARD) is if a user actually issued this via the RSCS CP command. > The RSCS CRI behavior should not have changed with z/VM 5.3, > it should be behaving the same way on older levels of z/VM. > > Best Regards, > Les Geer > IBM z/VM and Linux Development >
