Martin Thanks for your perseverance!
I had hoped that, from the discussion of the topic in my response to Bruce Richardson, you would have understood that I was trying to follow up on my suggestion that the IUTSAMEH interface was defined by CS IP even if DYNAMICXCF is *not* specified as a parameter of the IPCONFIG statement in the CS IP PROFILE data set: <quote> Stuart must not have DYNAMICXCF specified since that would avoid an IUTSAMEH interface being defined without a corresponding HOME list address. Maybe CS IP is so used to DYNAMICXCF being defined that - at some point - the "under-the-covers" IUTSAMEH interface is *always* defined and you just have to put up with that EZZ0331I message and you should - simply - ignore - it! If there is someone still reading this who has experience with CS IP *without* DYNAMICXCF who can state whether or not IUTSAMEH is defined automatically so much the better. </quote> The CS IP PROFILE definition which would illustrate this point and hence - in my rather joking manner - "qualify for the test" would have the following characteristics: - There would be no DYNAMICXCF parameter of the IPCONFIG statement - you have ticked that box - There would be no actual "manual" definition of the IUTSAMEH internal interface - you have *not* ticked that box Now if both of the above had applied to your CS IP PROFILE definition, the next step would be to examine the messages issued in the log of the CS IP address space as it is started. If the message EZZ0331I NO HOME ADDRESS ASSIGNED TO LINK IUTSAMEH had now appeared, it would indicate that the IUTSAMEH internal interface is created automatically despite DYNAMICXCF *not* having been specified as a parameter of the IPCONFIG statement in the CS IP PROFILE data set. If the message EZZ0331I NO HOME ADDRESS ASSIGNED TO LINK IUTSAMEH had not now appeared it would indicate that my guess for the reason that the message appeared in the log of the CS IP address space in Stuart Willis's first post is wrong - or just possibly other considerations apply. I checked Stuart Willis's log in his second post and I now see - which I hadn't before - that the offending message EZZ0331I NO HOME ADDRESS ASSIGNED TO LINK IUTSAMEH is no longer present in either of the two logs - confusion worse confounded! I guess I'm going to have to address Stuart Willis directly and ask what change he may have made between his first and second posts which might have caused that message no longer to appear. To answer your question: EZASAMEMVS is the name which I expect CS IP to use as the name in the LINK statement when it defines the IUTSAMEH internal interface automatically. I base this expectation on the name chosen when DYNAMICXCF is specified as a parameter of the IPCONFIG statement in the CS IP PROFILE data set. But your observation that you have a system where the EZZ0331I message appears is actually rather helpful. I now see that the EZZ0331I message in Stuart Willis's first post uses has the name IUTSAMEH and that this is the name in a LINK statement and not the name in the DEVICE statement. Thus whether automatically or manually, the definition of the IUTSAMEH internal interface corresponding to that log must have been, in essence if not completely: DEVICE IUTSAMEH MPCPTP LINK IUTSAMEH MPCPTP IUTSAMEH Thus the name is not EZASAMEMVS as would tend to be likely if my guess was correct. Note also that, fortunately, using the technical language which seems to be used for such matters, the name of the DEVICE statement and the name of the LINK statement do not "occupy the same name space". Thus the same name can be used for both the DEVICE and LINK statements in a pair. Thanks again for your help. Chris Mason On Fri, 20 Feb 2009 14:55:24 -0600, Martin Kline <[email protected]> wrote: >>Thanks for staying with this. > >>> If by "CS IP PROFILE" you mean the TCPIP parameteres pointed to by the >>>PROFILE DD statement in our TCPIP proc ... > >>Indeed I do. They are the statements described in Chapter 2, "TCP/IP profile >>(PROFILE.TCPIP) and configuration statements" in the z/OS Configuration >>Server (CS) IP Configuration Reference manual. > >>You would appear to qualify for this test since you don't have DYNAMICXCF >>defined as a parameter of your IPCONFIG statement. > >>Now take a look at the messages in the log of the CS IP address space, >>possibly under the name TCPIP, and see whether in the first 20 or so >>messages there is one which states > >>EZZ0331I NO HOME ADDRESS ASSIGNED TO LINK IUTSAMEH > >This message does not appear. > >>just as Stuart Willis reported in his original post. > >>However, also looking in the PROFILE data set, perhaps you can say whether >>or not you have coded a pair of DEVICE and LINK statements of the form > >>DEVICE IUTSAMEH MPCPTP >>LINK linkname MPCPTP IUTSAMEH > >Found: >DEVICE IUTSAMEH MPCPTP >LINK EELINK MPCPTP IUTSAMEH > >Also found: > 10.0.208.10 EELINK > >>If the answer is that you have defined such a pair of statements and you >>have also coded an entry in the HOME list assigning an IP address to >>linkname, then you don't qualify for this test! > >I don't qualify. Wait! What was I qualifying for? Was this a qualifying race or >certification thing or something? Weren't you just asking for an example? >Based on your original request, that's what I gave. Sorry you had something >else in mind. > >>If you have not defined such a pair of statements and you have no entry in >>the HOME list with the link name EZASAMEMVS, then you do qualify for this >>test. > >Now I'm confused. First, where did 'EZASAMEMVS' come from? Second, If I >have the DEVICE, LINK and HOME entry I don't qualify. If I have none of >those, I do qualify. What if I have the DEVICE and LINK but not the HOME >entry? That's the situation on one of our systems. > >Parameters: >DEVICE IUTSAMEH MPCPTP >LINK EELINK MPCPTP IUTSAMEH > >Message: >EZZ0331I NO HOME ADDRESS ASSIGNED TO LINK EELINK ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
