Re: HiperSockets

2008-06-15 Thread Martin, Terry R. (CMS/CTR) (CTR) 
Hi Alan,

Yes, you are correct:

In the HOME address specification I had the z/OS HiperSockets HOME
address below the VIPA HOME address. I do not have the z/OS's IP
address defined in the z/VM TCP/IP configuration. Sorry for the
confusion and thanks for clearing it up.

Terry


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Sunday, June 15, 2008 1:04 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: HiperSockets

On Friday, 06/13/2008 at 10:08 EDT, Martin, Terry R. (CMS/CTR) (CTR) 
[EMAIL PROTECTED] wrote:
 With the help of IBM support we were able to figure out my problem. It
 turns out that we have a Source VIPA defined and active on the z/OS
 LPAR. In the HOME address specifications I had the z/VM HOME address
 below the VIPA HOME address. When I Pinged VM it wanted to respond
back
 via the VIPA HOME IP address which was different than the HOME IP
 address that I had defined for the z/OS LPAR in TCPIP in VM. As a
simple
 correction I changed the order of the HOME addresses on the z/OS side
 putting the VM HOME IP address above the VIPA HOME IP address then the
 PING was successful.

I'm glad you got it figured out, but your post is confusing to me.  I 
don't understand why you have z/VM's HOME address defined in you z/OS 
config, and vice versa.  I think you meant In the HOME address 
specification I had the z/OS HiperSocket HOME address below the VIPA
HOME 
address.  Likewise, you would not define z/OS's IP addresses in the
z/VM 
TCP/IP config.

But, yes, SourceVIPA can mess things up if you're not running dynamic 
routing daemons everywhere. 

Alan Altmark
z/VM Development
IBM Endicott

Re: RMSMASTR FSMKIN1100E Error from communication function 24, return

2008-06-15 Thread Alan Altmark 
On Friday, 06/13/2008 at 04:14 EDT, Les Geer (607-429-3580) 
[EMAIL PROTECTED] wrote:
 In addition, the error message indicates an IUCV CONNECT failure
 to *IDENT.  Not sure if that is RMSMASTR encountering this failure
 (I suspect so), or the user ID you are issuing the DFSMSRM command
 from.   You may have to authorize user IDs to *IDENT in RACF (I
 don't know this for sure).   Basically, you will need to duplicate
 the authorizations you did first level to the second level, assuming
 you are using RACF first level for RMS authorization.

There are no RACF controls on *IDENT.  You must have an IUCV *IDENT 
statement in the user who is creating a global, local, or system resource. 


Alan Altmark
z/VM Development
IBM Endicott