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. 

And yes, there is an open PMR for this.

Only Chuckie would alter the altar, or is it altar the alter, like that 
purposely:-) 
  

Regards, 
Richard Schuh 

 

> -----Original Message-----
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> Sent: Thursday, November 12, 2009 10:08 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: SFS and CP Question
> 
> On Thursday, 11/12/2009 at 12:07 EST, "Schuh, Richard" 
> <rsc...@visa.com>
> wrote:
> > So it depends on the release of VM. Anyone running a release older 
> > than
> 5.3 
> > will have a problem. So much for backward compatibility.
> 
> As to the RSCS CRI, do you mean that your programs using the 
> CRI didn't spell out the command name and got caught by the 
> abbreviation change?  I'm fairly certain that RSCS doesn't 
> issue the CP FORWARD command on his own.
> 
> In any case, the number of people with channel-attached 
> printers on z/VM is getting pretty darned low.  We chose to 
> sacrifice FO on the alter of progress rather than create an 
> unintuitive command (8 letters isn't a lot).  Sure, there's a 
> bit of grumbling from one or two people, but the world 
> continues to turn on its axis.  When we made TCP/IP low port 
> numbers protected by default, that was a much larger 
> incompatibility, and people got past it.
> 
> But don't worry, the world-renown "IBM Mainframe Hoops of 
> Compatibility" 
> are still installed here.  But they are flaming *hoops*, not 
> solid lead Discs of Doom.  :-)
> 
> Alan Altmark
> z/VM Development
> IBM Endicott
> 

Reply via email to