Martin (and Ed Finnell) Well, as you can see from Stuart Willis's latest post, this has been something of a wild goose chase. There is still a mystery but it does not involve Communications Server (CS) IP creating the IUTSAMEH interface definition dynamically.
The mystery is why CS IP selects an attempt to activate presumably - if I dare to assume anything after this episode! - any interface as an excuse to complain about the IUTSAMEH interface definition lacking an address defined in the HOME list. I'm sorry for all the fuss. Chris Mason On Sat, 21 Feb 2009 03:13:42 -0600, Chris Mason <[email protected]> wrote: >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
