Re: RECEIVE ORDER ERROR
In defense of selective RECEIVE. Maybe it's because we have several folks 'in charge' of various products; more likely it's because I'm a very disorganized person. I can't keep track of what I should or should not APPLY other than 'all'. Besides IBM's classifications, I get occasional requests from other people to install a PTF or two for the specific product they support. They're all grown-ups. I don't question whether MQ or HSM or IP really does or does not need a particular fix suggested by the respective SME. If I RECEIVE(ALL), how will I keep of what I should APPLY in the next cycle? (Rhetorical question. Suggestions not solicited.) Since I'm not fully capable of any procedure other RECEIVing selectively and then APPLYing all, that will remain my SOP. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com "Chase, John" To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List Re: RECEIVE ORDER ERROR 04/28/2009 03:36 PM Please respond to IBM Mainframe Discussion List > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Mark Zelden > > On Tue, 28 Apr 2009 13:11:43 -0700, Edward Jaffe wrote: > > >Chase, John wrote: > >>> If I did that, wouldn't I have all of the PTFs that haven't yet gone > >>> through CST? > >>> > >> > >> Yes, but you can APPLY by SOURCEID(RSU*). > >> > > > >Right now, I just RECEIVE ORDER CONTENT(RECOMMENDED), whatever comes > >back comes back, and I APPLY *all* of it with a "canned" job stream > >that's always the same. Simple. > > > >The suggestion seems to be to use RECEIVE ORDER CONTENT(ALL) and then > >selectively manage what comes back. I become the one who decides which > >fixes have undergone enough testing and which have not. I have to keep > >track of these numbered/dated RSUs to help understand which fixes I want > >and which I don't. And, I have to be sure to specify the right RSU > >value(s) at APPLY time. > > > > From where I sit, this process sounds like extra work. Clearly, this is > >a job to be undertaken by a professional sysprog--something I've never > >claimed to be. > > > > Not any extra work at all. It's just changing where the "filter" is. > > Currently you filter at the source by selecting "CONTENT(RECOMMENDED)". > If you change to "CONTENT(ALL)" and change your APPLY JCL to > "SOURCEID(RSU*)", you are applying the same service. The "PRO" is that > you would have any PTF you needed in an emergency. The "CONs" are > possibly longer download times and storing more PTFs locally. Actually, to apply *everything* you get with CONTENT(RECOMMENDED), you'd need to specify SOURCEIDs RSU*, HIPER and PRP. I've tried it already with one "batch" of CICS maintenance, using this "canned" APPLY job: APPLY FORFMID( list of CICS FMIDs ) SOURCEID( RSU* HIPER PRP ) GROUPEXTEND BYPASS( whatever's appropriate for your case) CHECK . "Works a treat." -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Mark Zelden > > On Tue, 28 Apr 2009 13:11:43 -0700, Edward Jaffe wrote: > > >Chase, John wrote: > >>> If I did that, wouldn't I have all of the PTFs that haven't yet gone > >>> through CST? > >>> > >> > >> Yes, but you can APPLY by SOURCEID(RSU*). > >> > > > >Right now, I just RECEIVE ORDER CONTENT(RECOMMENDED), whatever comes > >back comes back, and I APPLY *all* of it with a "canned" job stream > >that's always the same. Simple. > > > >The suggestion seems to be to use RECEIVE ORDER CONTENT(ALL) and then > >selectively manage what comes back. I become the one who decides which > >fixes have undergone enough testing and which have not. I have to keep > >track of these numbered/dated RSUs to help understand which fixes I want > >and which I don't. And, I have to be sure to specify the right RSU > >value(s) at APPLY time. > > > > From where I sit, this process sounds like extra work. Clearly, this is > >a job to be undertaken by a professional sysprog--something I've never > >claimed to be. > > > > Not any extra work at all. It's just changing where the "filter" is. > > Currently you filter at the source by selecting "CONTENT(RECOMMENDED)". > If you change to "CONTENT(ALL)" and change your APPLY JCL to > "SOURCEID(RSU*)", you are applying the same service. The "PRO" is that > you would have any PTF you needed in an emergency. The "CONs" are > possibly longer download times and storing more PTFs locally. Actually, to apply *everything* you get with CONTENT(RECOMMENDED), you'd need to specify SOURCEIDs RSU*, HIPER and PRP. I've tried it already with one "batch" of CICS maintenance, using this "canned" APPLY job: APPLY FORFMID( list of CICS FMIDs ) SOURCEID( RSU* HIPER PRP ) GROUPEXTEND BYPASS( whatever's appropriate for your case) CHECK . "Works a treat." -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Mark Zelden wrote: Not any extra work at all. It's just changing where the "filter" is. Currently you filter at the source by selecting "CONTENT(RECOMMENDED)". If you change to "CONTENT(ALL)" and change your APPLY JCL to "SOURCEID(RSU*)", you are applying the same service. The "PRO" is that you would have any PTF you needed in an emergency. The "CONs" are possibly longer download times and storing more PTFs locally. Got it! And, Richard Peurifoy points out that CONTENT(RECOMMENDED) probably also contains HIPERs and other things. So, I would need to know those SOURCEIDs to get equivalent function. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
On Tue, 28 Apr 2009 13:38:57 -0700, Edward Jaffe wrote: >Richard Peurifoy wrote: >> If you want to apply all RSU maintenance, you can specify >> RSU* on the APPLY. > >How does the RSU SOURCEID find its way to a PTF I previously >RECEIVEd? Does SMP/E add missing SOURCEIDs automatically when I do >RECEIVE ORDER? > Yes. Adding SOURCEID via ++ASSIGN after the sysmod is already in receive status was implemented in SMP/E 3.4 IIRC. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
On Tue, 28 Apr 2009 13:11:43 -0700, Edward Jaffe wrote: >Chase, John wrote: >>> If I did that, wouldn't I have all of the PTFs that haven't yet gone >>> through CST? >>> >> >> Yes, but you can APPLY by SOURCEID(RSU*). >> > >Right now, I just RECEIVE ORDER CONTENT(RECOMMENDED), whatever comes >back comes back, and I APPLY *all* of it with a "canned" job stream >that's always the same. Simple. > >The suggestion seems to be to use RECEIVE ORDER CONTENT(ALL) and then >selectively manage what comes back. I become the one who decides which >fixes have undergone enough testing and which have not. I have to keep >track of these numbered/dated RSUs to help understand which fixes I want >and which I don't. And, I have to be sure to specify the right RSU >value(s) at APPLY time. > > From where I sit, this process sounds like extra work. Clearly, this is >a job to be undertaken by a professional sysprog--something I've never >claimed to be. > Not any extra work at all. It's just changing where the "filter" is. Currently you filter at the source by selecting "CONTENT(RECOMMENDED)". If you change to "CONTENT(ALL)" and change your APPLY JCL to "SOURCEID(RSU*)", you are applying the same service. The "PRO" is that you would have any PTF you needed in an emergency. The "CONs" are possibly longer download times and storing more PTFs locally. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Ed, If you start at http://www-03.ibm.com/servers/eserver/zseries/zos/servicetst/ and sniff around and about, you'll eventually find most of the answers you're looking for. Bob Edward Jaffe wrote: Richard Peurifoy wrote: If you want to apply all RSU maintenance, you can specify RSU* on the APPLY. How does the RSU SOURCEID find its way to a PTF I previously RECEIVEd? Does SMP/E add missing SOURCEIDs automatically when I do RECEIVE ORDER? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Edward Jaffe wrote: Richard Peurifoy wrote: If you want to apply all RSU maintenance, you can specify RSU* on the APPLY. How does the RSU SOURCEID find its way to a PTF I previously RECEIVEd? Does SMP/E add missing SOURCEIDs automatically when I do RECEIVE ORDER? I can't speak to RECEIVE ORDER, we aren't using it yet. Traditionally when you receive hold data, it includes updates to sourceid's. Because we aren't using RECEIVE ORDER, I also don't know if CONTENT(RECOMMENDED) is the same as RSU maintenance. I was just trying to point out a way to APPLY all RSU maintenance without having to keep up with RSU numbers. If HIPER's are included in CONTENT(RECOMMENDED), you would want to include them as well. -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Eatherly, John D[EQ] wrote: Hold data would add the SOURCEIDs after the PTF is received. OK. In that case, the suggestion is that I use RECEIVE ORDER CONTENT(ALL) and use APPLY SOURCEID(RSU*) to ensure only "recommended" maintenance gets applied. All other received service waits in my PTS until an RSU SOURCEID gets assigned via HOLDDATA at which time it gets applied? Are there ever any PTFs that *never* get RSU SOURCEIDs assigned? Will every PTF get applied eventually? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Hold data would add the SOURCEIDs after the PTF is received. Thanks John Eatherly How does the RSU SOURCEID find its way to a PTF I previously RECEIVEd? Does SMP/E add missing SOURCEIDs automatically when I do RECEIVE ORDER? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Richard Peurifoy wrote: If you want to apply all RSU maintenance, you can specify RSU* on the APPLY. How does the RSU SOURCEID find its way to a PTF I previously RECEIVEd? Does SMP/E add missing SOURCEIDs automatically when I do RECEIVE ORDER? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Edward Jaffe wrote: Chase, John wrote: If I did that, wouldn't I have all of the PTFs that haven't yet gone through CST? Yes, but you can APPLY by SOURCEID(RSU*). Right now, I just RECEIVE ORDER CONTENT(RECOMMENDED), whatever comes back comes back, and I APPLY *all* of it with a "canned" job stream that's always the same. Simple. The suggestion seems to be to use RECEIVE ORDER CONTENT(ALL) and then selectively manage what comes back. I become the one who decides which fixes have undergone enough testing and which have not. I have to keep track of these numbered/dated RSUs to help understand which fixes I want and which I don't. And, I have to be sure to specify the right RSU value(s) at APPLY time. From where I sit, this process sounds like extra work. Clearly, this is a job to be undertaken by a professional sysprog--something I've never claimed to be. I think I'll stick with simple... If you want to apply all RSU maintenance, you can specify RSU* on the APPLY. Is CONTENT(RECOMMENDED) different than RSU? -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Chase, John wrote: If I did that, wouldn't I have all of the PTFs that haven't yet gone through CST? Yes, but you can APPLY by SOURCEID(RSU*). Right now, I just RECEIVE ORDER CONTENT(RECOMMENDED), whatever comes back comes back, and I APPLY *all* of it with a "canned" job stream that's always the same. Simple. The suggestion seems to be to use RECEIVE ORDER CONTENT(ALL) and then selectively manage what comes back. I become the one who decides which fixes have undergone enough testing and which have not. I have to keep track of these numbered/dated RSUs to help understand which fixes I want and which I don't. And, I have to be sure to specify the right RSU value(s) at APPLY time. From where I sit, this process sounds like extra work. Clearly, this is a job to be undertaken by a professional sysprog--something I've never claimed to be. I think I'll stick with simple... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe > > Brian Peterson wrote: > > Yet another problem I never saw because I always use CONTENT(ALL) instead of > > CONTENT(RECOMMENDED) for RECEIVE ORDER. > > > > http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0904&L=ibm-main&P=R14311 > > > > You too could see the light and choose to move to using CONTENT(ALL).. > > > > If I did that, wouldn't I have all of the PTFs that haven't yet gone > through CST? Yes, but you can APPLY by SOURCEID(RSU*). > And, if CONTENT(ALL) is recommended, why is there CONTENT(RECOMMENDED)? Indeed. I had a somewhat similar problem with CONTENT(RECOMMENDED) for a brand-new CSI that had nothing but the product FMID in it. CONTENT(RECOMMENDED) retrieved nothing, with a message along the lines of "no sysmods satisfied filter criteria". A subsequent RECEIVE ORDER ... CONTENT(ALL) got about 50 PTFs, ALL of which had an RSU SOURCEID. I agree with what appears to be your underlying premise: If an option is offered, it ought to work "always". -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
On Tue, 28 Apr 2009 08:05:47 -0700, Edward Jaffe wrote: >Brian Peterson wrote: >> Yet another problem I never saw because I always use CONTENT(ALL) instead of >> CONTENT(RECOMMENDED) for RECEIVE ORDER. >> >> http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0904&L=ibm-main&P=R14311 >> >> You too could see the light and choose to move to using CONTENT(ALL).. >> > >If I did that, wouldn't I have all of the PTFs that haven't yet gone >through CST? > Yes. But that doesn't mean you have to apply them all. >And, if CONTENT(ALL) is recommended, why is there CONTENT(RECOMMENDED)? > Recommended by Brian. :-) I have seen plenty of recommendations for applying service (including some very nice SHARE presentations in recent years from Greg Daynes), but I don't recall any specific recommendation to use CONTENT(ALL) from IBM. However, if you aren't concerned about space in the SMPPTS(es), then I wholeheartedly agree (this shouldn't be an issue for practically all shops these days). Better to have a PTF sitting in your SMPPTS ready to apply in an emergency than having to rely on RECEIVE ORDER, ShopZ or any other method of PTF delivery when the server on the other end may not be working. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Brian Peterson wrote: Yet another problem I never saw because I always use CONTENT(ALL) instead of CONTENT(RECOMMENDED) for RECEIVE ORDER. http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0904&L=ibm-main&P=R14311 You too could see the light and choose to move to using CONTENT(ALL).. If I did that, wouldn't I have all of the PTFs that haven't yet gone through CST? And, if CONTENT(ALL) is recommended, why is there CONTENT(RECOMMENDED)? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Yet another problem I never saw because I always use CONTENT(ALL) instead of CONTENT(RECOMMENDED) for RECEIVE ORDER. http://alabamamaps.ua.edu/cgi-bin/wa?A2=ind0904&L=ibm-main&P=R14311 You too could see the light and choose to move to using CONTENT(ALL).. Brian On Sat, 25 Apr 2009 22:00:52 -0400, Edward Jaffe wrote: >Been getting this all weekend trying RECEIVE ORDER with >CONTENT(RECOMMENDED). Am I the only one? > >Error encountered during CCSS processing when >requested fix co >uld not be found.. > >Edward E Jaffe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
On Sun, 26 Apr 2009 15:08:35 -0500, Field, Alan C. wrote: >Here's more of the explanation: > >"Order B8456491 was Rejected at 06:50:56 04/23/2009 >UA46439 >(CO-REQ) <--- Fix not found >. >From the above, the order failed as Co-Req UA46439 was not found. >Looking at UA46439, it has been closed Cancel. This will need to be >addressed by the ptf owners, DFSMSHSM. UA46439 should still not be >being called out if it has been cancelled." > Understood. Perhaps there was a process violation: when a PTF is canceled, should all dependent PTFs be canceled alike? This may be impractical, sometimes involving an inordinate amount of rework. An alternative is to provide HOLDDATA: ++ HOLD( UA46439 ) ERROR REASON( UA46640 ) ... etc. to cause SMP/E to seek the COR PTF when UA46439 is called out. Alas, I fear I've had such discussions (dare I say disagreements) with our own development leaders: "Why bother with ++HOLD ERROR if the PTF is CANcelled and will never be distributed?" This scenario provides the reason. The counter argument is that ++HOLD ERROR creates a bad impression whether with customers or performance review. And in the OP's text, I see much ShopZ jargon, as opposed to SMP/E. Is it possible that ShopZ fails to understand SMP/E's processing or to reflect its structures fully? If so, so much the worse for ShopZ. My present (for the time being) employer's web site has a much richer structure than my former (in a manner of speaking) employer's. I now work for a company with a more significant software LOB. Their service web site has a concept of PRErequisite and SUPERsede (only the jargon is different). More dismaying is that the rules differ. The structure welcomed by SMP/E: ++ PTF( A ) ... ++ PTF( B ) ... PRE( A ) ... ++ PTF( C ) ... PRE( B ) SUP( A ) ... is rejected as an "unhealthy relationship". For the time being, I am not reflecting SUPs to the web site protocol (they _do_ remain effective in the PTF body). I have a battle to fight here. In the short term, I'm pessimistic: there's too much else occurring. In the long term (if I last so long) there may be more hope. We may (probably) be metamorphosing into a company with not only a significant software LOB, but even a z/OS software LOB. Time will tell. >On Sat, 25 Apr 2009 21:09:48 -0500, Field, Alan C. wrote: >> >>this problem with the cancelled PTF that is co-req'd by the PTFs in >>SDM and DSS. HSM PTF's UA46642 UA46641 UA46640 were created and now >>closed COR, and these supercede the cancelled PTFs. So if you pull >>these you should be able to get the maintenance on. It appears the >>problem is that the SDM and DSS PTFs call for the cancelled HSM PTF >>instead of its superceding PTF. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Here's more of the explanation: "Order B8456491 was Rejected at 06:50:56 04/23/2009 UA46439 (CO-REQ) <--- Fix not found . >From the above, the order failed as Co-Req UA46439 was not found. Looking at UA46439, it has been closed Cancel. This will need to be addressed by the ptf owners, DFSMSHSM. UA46439 should still not be being called out if it has been cancelled." -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Sunday, April 26, 2009 10:07 To: IBM-MAIN@bama.ua.edu Subject: Re: RECEIVE ORDER ERROR On Sat, 25 Apr 2009 21:09:48 -0500, Field, Alan C. wrote: > >I've asked our developers to investigate what we can do to clear up >this problem with the cancelled PTF that is co-req'd by the PTFs in >SDM and DSS. HSM PTF's UA46642 UA46641 UA46640 were created and now >closed COR, and these supercede the cancelled PTFs. So if you pull >these you should be able to get the maintenance on. It appears the >problem is that the SDM and DSS PTFs call for the cancelled HSM PTF >instead of its superceding PTF. > ??? It has long been my understanding that a SUPerseding sysmod unconditionally satisfies any requirement for the superseded sysmod. Is it a structural problem in that there's no HOLDDATA to cause GROUPEXTEND to work? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
On Sat, 25 Apr 2009 21:09:48 -0500, Field, Alan C. wrote: > >I've asked our developers to investigate what we can do to clear up >this problem with the cancelled PTF that is co-req'd by the PTFs in >SDM and DSS. HSM PTF's UA46642 UA46641 UA46640 were created and now >closed COR, and these supercede the cancelled PTFs. So if you pull >these you should be able to get the maintenance on. It appears the >problem is that the SDM and DSS PTFs call for the cancelled HSM PTF >instead of its superceding PTF. > ??? It has long been my understanding that a SUPerseding sysmod unconditionally satisfies any requirement for the superseded sysmod. Is it a structural problem in that there's no HOLDDATA to cause GROUPEXTEND to work? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Field, Alan C. wrote: Ed, No. I opened a problem with IBM. The problem is caused by a DFHSM PTF. [snip] I downloaded these PTFS then my RECEIVEORDER worked. That did it! Thanks! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RECEIVE ORDER ERROR
Ed, No. I opened a problem with IBM. The problem is caused by a DFHSM PTF. Here's the circumvention from IBM: I've asked our developers to investigate what we can do to clear up this problem with the cancelled PTF that is co-req'd by the PTFs in SDM and DSS. HSM PTF's UA46642 UA46641 UA46640 were created and now closed COR, and these supercede the cancelled PTFs. So if you pull these you should be able to get the maintenance on. It appears the problem is that the SDM and DSS PTFs call for the cancelled HSM PTF instead of its superceding PTF. I'll let you know what our resolution is to prevent this from happening to other customers. Please let me know if you have problems after pulling the superceding PTFs. I downloaded these PTFS then my RECEIVEORDER worked. Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Saturday, April 25, 2009 21:01 To: IBM-MAIN@bama.ua.edu Subject: RECEIVE ORDER ERROR Been getting this all weekend trying RECEIVE ORDER with CONTENT(RECOMMENDED). Am I the only one? HTTP/1.1 500 Internal Server Error. Date: Sun, 26 Apr 2009 01:33:27 GMT. Server: IBM_HTTP_Server/6.0.2.33 Apache/2.0.47 (Unix). Content-Length: 797. Content-Type: text/xml; charset=utf-8. Content-Language: en-US. Connection: close. . . http://schemas.xmlsoap.org/soap/envelope/"; xmln s:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:xsd="http://www.w3.o rg/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>. . . . http://www.ibm.com/xmlns/b2b/ecc/v1.0";>p760:Client.Object NotFound. com.ibm.ecc.protocol.ClientObjectNotFound. . http://www.ibm.com/xmlns/b2b/ecc/v1.0";>. Error encountered during CCSS processing when requested fix co uld not be found.. . UA46439. . . . . . -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Receive Order Error
Thanks to everyone who responsed to our Receive Order problem. We added GLOBALTCPIPDATA, GLOBALIPNODES, and COMMONSEARCH for RESOLVER. It fixed the problem and our Receive Order ran fine. Also, we authorized the PING command by added it to AUTHCMD in IKJTSOxx. Dick Very helpful information from Chris Mason - Because IPv4 with NOCOMMONSEARCH, the default, requires the creation of the HOSTS.ADDRINFO and HOSTS.SITEINFO files from the HOSTS.LOCAL file using the MAKESITE utility - which is very irritating - specifying the COMMONSEARCH "resolver setup statement" and using an "ipnodes" formatted data set - which can be edited and used straight away is massively to be preferred. But "chacun à son goût". Still keeping in mind why we are here, Dick may succeed once he has got access to the public name servers sorted out[1]. However if there is still some hang-up over using name servers, he may prefer to use a local file, at least in the interim, in which he may wish to use a local file. If he sets himself up to use the "ipnodes" format in, say, TCPIP.ETC.IPNODES, he can set up minimally the statement 207.25.253.62 inetsd01.boulder.ibm.com Well, I checked back and actually, whatever is in the file which Dick specified in the SYSTCPD DD-statement works since, although the PING failed, the name lookup succeeded. It's just a matter of specifying that file as the universal "client data file" (TCPIP.DATA) using the GLOBALTCPIPDATA "resolver setup statement" - and everything should work. Chris Mason -- 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
Re: Receive Order Error
Brian COMMONSEARCH affects only the name to address and address to name function of the "resolver". It does *not* affect where the "client data set" (TCPIP.DATA) is to be found. The influence of COMMONSEARCH, one of the "resolver setup statements", can be seen when the SETUP statement, one of the "client data set" (TCPIP.DATA), statements, specifies LOCAL, namely that a file is to be used to perform the conversion of name to address or address to name rather than or in addition to using the name server which is indicated by specifying DNS. If a file is to be used, the following rules determine which file and, consequently, which format. Here are more of the notes I created for that earlier post I mentioned in my response to Mark's post: Local host tables = Used if specified by - LOOKUP LOCAL in "client data" file - TCP/IP C/C++ API applications with a RESOLVE_VIA_LOOKUP symbol in source - a testing facility IPv4 with NOCOMMONSEARCH * Environment variable - X_ -> x.HOSTS.INFO * /etc/hosts # x.HOSTS.INFO hlq.HOSTS.INFO TCPIP.HOSTS.INFO * only UNIX # x is userid for UNIX and userid/jobname/procname for MVS is ADDR for address information and SITE for site information Format: "HOSTS.LOCAL" (RFC 952) CS IP Configuration Guide. section 1.5.4.2.2, "NET and GATEWAY entries" "hosts" CS IP Configuration Guide. section 2.5.5.7, "Configuring host resolvers: onslookup considerations". Used for IPv4 addresses confirmed in section 1.5.4.1, "Why configure a local host table?" IPv6 or IPv4 with COMMONSEARCH -- Resolver - GLOBALIPNODES * Environment variable - RESOLVER_IPNODES # x.ETC.IPNODES hlq.ETC.IPNODES TCPIP.ETC.IPNODES Resolver - DEFAULTIPNODES /etc/ipnodes * only UNIX # x is userid for UNIX and userid/jobname/procname for MVS Format: "ipnodes" CS IP Configuration Guide. section 1.5.4.4, "Creating ETC.IPNODES and /etc/ipnodes" Because IPv4 with NOCOMMONSEARCH, the default, requires the creation of the HOSTS.ADDRINFO and HOSTS.SITEINFO files from the HOSTS.LOCAL file using the MAKESITE utility - which is very irritating - specifying the COMMONSEARCH "resolver setup statement" and using an "ipnodes" formatted data set - which can be edited and used straight away is massively to be preferred. But "chacun à son goût". Still keeping in mind why we are here, Dick may succeed once he has got access to the public name servers sorted out[1]. However if there is still some hang-up over using name servers, he may prefer to use a local file, at least in the interim, in which he may wish to use a local file. If he sets himself up to use the "ipnodes" format in, say, TCPIP.ETC.IPNODES, he can set up minimally the statement 207.25.253.62 inetsd01.boulder.ibm.com Well, I checked back and actually, whatever is in the file which Dick specified in the SYSTCPD DD-statement works since, although the PING failed, the name lookup succeeded. It's just a matter of specifying that file as the universal "client data file" (TCPIP.DATA) using the GLOBALTCPIPDATA "resolver setup statement" - and everything should work. Chris Mason [1] Maybe, also Dick can find out how to authorise the use of PING commands but that's not the immediate problem. - Original Message - From: "Brian Peterson" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Monday, 30 October, 2006 9:31 PM Subject: Re: Receive Order Error > Mark, you're absolutely right. I've been looking at the books and they can > set up a global search order using the RESOLVER function of TCP/IP. That > way, every address space would get the right set of TCPIP.DATA values, no > matter what they happened to specify. > > According to the books, one of the defaults within RESOLVER is > NOCOMMONSEARCH. Apparently, setting this to COMMONSEARCH allows the > installation to move away from the so-called "standard search order" and > instead have one place to define their TCPIP.DATA parameters. I use the > phrase "so-called" because the "standard search order" is ugly and hard to > understand (in my opinion) because it reflects the evolution of TCP/IP on > z/OS - based upon the API used, a totally different "standard search order" > for TCPIP.DATA parameters applies. COMMONSEARCH overcomes this by imposing > a new site-wide value. > > At least, that's what I've learned so far. Now, I'm off to try it! > > Brian -- 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
Re: Receive Order Error
Mark This is the immensely complicated complete story as I worked it out for a query earlier this year. I hope it hasn't been made any more complicated in the meantime. Base resolver configuration files - Resolver - GLOBALTCPIPDATA plus the first of the following% * Environment variable - RESOLVER_CONFIG * /etc/resolv.conf //SYSTCPD DD statement # x.TCPIP.DATA SYS1.TCPPARMS(TCPDATA) Resolver - DEFAULTTCPIPDATA TCPIP.TCPIP.DATA * only UNIX # x is userid for UNIX and userid/jobname/procname for MVS % If GLOBALTCPIPDATA used, the following are completely specified there: DomainOrigin/Domain NSInterAddr/NameServer NSPortAddr ResolverTimeOut ResolverUDPRetries ResolveVia Search SortList The following may also be found in the "search order" data set: ALWAYSWTO DATASETPREFIX HOSTNAME LOADDBCSTABLES LOOKUP MESSAGECASE OPTIONS SOCKDEBUG SOCKNOTESTSTOR SOCKTESTSTOR TCPIPJOBNAME TCPIPUSERID TRACE RESOLVER TRACE SOCKET This is an extract of the complete story on "Resolver search orders". "UNIX" applies to processes/programs which use the "UNIX environment" and, from your post, this "RECEIVE" function would appear to be one of those. "MVS" applies to processes/programs which use the "MVS environment". I can see two approaches. 1. Use "/etc/resolv.conf" in order to specify access to the name server system and verify with an onslookup command once in "UNIX" mode. 2. Go to the bother - probably worth it in the long term - of creating a RESOLVER cataloged procedure which identifies a file to contain the "resolver setup statements" which uses the GLOBALTCPIPDATA statement in order to identify a set of "resolver" or "TCPIP.DATA" statements, a file I used to teach as the "client data file", recalling that "client" in this case referred to all processes which relied on the main TCP/IP address space, whether logically, really "clients" such as TSO users, or "servers" such as, well, FTP. This is nearly all documented in Chapter 5, "TCPIP.DATA configuration statements" (1.5) of the z/OS V1R7.0 Communications Server IP Configuration Reference manual.The missing piece is the RESOLVER_PROC statement in the BPXPRMxx parmlib member. The RESOLVER_PROC statement in the BPXPRMxx parmlib member is covered in section 1.2.5.1, "Setting up a resolver address space" in the z/OS V1R7.0 Communications Server IP Configuration *Guide* manual - of all places. It may be useful to check out the whole 1.2.5, "Understanding resolvers" section. Because you can see a RESOLVER address space running, you may assume you must already have a RESOLVER started task procedure . This is not necessarily so. This is "smoke and mirrors" caused by subtle use of the IEESYSAS started task procedure (analyse what START IEESYSAS.RESOLVER,PROG=EZBREINI,SUB=MSTR means). I checked Pat O'Keefe's post and happily we are in agreement over the influence of GLOBALTCPIPDATA. We must have been reading the same manual. Thanks for the explanation of why the SYSTCPD DD-statement doesn't work. That helps resolve (sic) the issues here. Chris Mason - Original Message - From: "Gibbons, Mark" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Monday, 30 October, 2006 8:22 PM Subject: Re: Receive Order Error > As far as I can tell. Internet retrieval creates and uses a unix process in another address space to retrieve orders. The systcpd dd statement is not passed to the new address space. The only method I've found that works is to have the data be found in the standard tcp search order. I'm not sure what the standard search order is (tcp config reference lookup a while back) but it will find: > > userid.TCPIP.DATA > SYS1.TCPPARMS(TCPDATA) > something in /etc/ > > IBM needs to let us specify this data for the receive. Much like they do the other information for client and orderserver. I'd be very happy if I was wrong however. We don't have our tcpd data in the standard search order. > > Mark -- 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
Re: Receive Order Error
Brian What this shows is that Dick needs to ensure that the userid associated with the batch TSO job - if he followed your advice rather than just putting the SYSTCPD DD-statement in a TSO logon procedure in which case it would simply be the TSO userid - needs to be authorised to run programs which need to open "raw" sockets, such a program being PING needing to run protocol ICMP. Chris Mason - Original Message - From: "Brian Peterson" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Friday, 27 October, 2006 9:33 PM Subject: Re: Receive Order Error > OK - This result shows that the SYSTCPD DD statement is required for your > RECEIVE job, and should fix your problem where RECEIVE is unable to resolve > the inetsd01.boulder.ibm.com address - the "unknown host" error. > > So, if you add SYSTCPD to your RECEIVE job, you should expect to get some > result OTHER than: > > >SC0508 initConnection: Calling getaddrinfo() with inetsd01.boulder.ibm.com > >SC0517 initConnection: getaddrinfo() resptr 0 rc 1/EDC9501I The name does > >not re > >solve for the supplied parameters. (errno2=0x112B) > >Unknown host: inetsd01.boulder.ibm.com > > Again, I'm not saying this will fix every problem and make the RECEIVE job > work. It is a required first step. You first must be able to resolve via > DNS the IP address of inetsd01.boulder.ibm.com before your RECEIVE job will > attempt to connect from your system to that host - via whatever obstacles > your network implementation imposes (proxys, firewalls, etc). > > Once SMP/E attempts to connect to the IBM host, then the issues of proxy or > firewall come into play. > > Brian > > On Fri, 27 Oct 2006 14:50:04 -0500, Dick Renneke wrote: > > >With the SYSTCPD DD statement, we got this response - > > > >READY > > PING INETSD01.BOULDER.IBM.COM > >CS V1R7: Pinging host INETSD01.BOULDER.IBM.COM (207.25.253.62) > >READY > >END > >Unable to open RAW socket: EDC5139I Operation not permitted. -- 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
Re: Receive Order Error
Dick This used to mean that you hadn't authorized your TSO user to run protocol ICMP which is required by PING. TCP/IP for VM and its descendants such as Communications Server IP use what they call "raw" sockets in order to run protocols other than TCP and UDP. 10 to 12 years ago, I used to teach to the following: - Extracted from the visual: ; Authorized Procedures and UserIDs INFORM MASTER ENDINFORM OBEY ICMPMON MASTER NCPROUTE ROUTED SNMPD SNMPQE ENDOBEY - And from the notes: Authorized Procedures and UserIDs - The INFORM statement list (delimited by ENDINFORM) specifies a list of operators to be sent messages for serious run-time error conditions. The author has never suffered any such conditions and so cannot say exactly how such messages appear to a logged-on TSO user. The OBEY statement list (delimited by ENDOBEY) specifies a list of operators who are able to issue OBEYFILE commands. The OBEYFILE command refers to a data set which contains a (re-)specification of statements in the "profile" data set and so may be used to define new links and stop and start links. For details of exactly how, for example, list statements are handled the Customization and Administration Guide manual should be consulted. The OBEY list also authorizes the use of NETSTAT commands with the DROP option. Lastly, the OBEY list authorizes a user, identified either as the TSO userid or the started task procedure name, to issue the socket() call specifying "raw" sockets, SOCK_RAW, as opposed to stream or datagram, SOCK_STREAM or SOCK_DGRAM respectively. This facility is required to be able to access, for example, ICMP packets and, hence, the started task procedure name for ICMP monitor program[1] is included here.[2] [1] This was a program of mine which I used on my test systems - used by students' hands-on - which placed a hexadecimal record in the log of all ICMP packets received. It was one of the fun programs I wrote to be sure I had taught myself C and sockets successfully. [2] Oddly enough the only TSO userid specified in this example was MASTER which is the userid I used on my test systems. I'm sure the full "OBEY" list had all the userids I provided for student use. Checking "OBEY" today, I see that there is no longer an OBEY/ENDOBEY list in the PROFILE. Perhaps it is all covered by the OUTBOUND_RAW statement in section 2.16.23, "IDSAttackCondition" - whatever that's all about. Am I getting old that I regard this as over-elaboration of something simple? I guess the developers need something to do but it all seems to be in a, possibly vain, attempt to create full employment for long-suffering system programmers. Incidentally, as you may have discovered, the explanation of what to do with message "Unable to open RAW socket: EDC5139I Operation not permitted." is totally useless. Chris Mason - Original Message - From: "Dick Renneke" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Friday, 27 October, 2006 8:50 PM Subject: Re: Receive Order Error > With the SYSTCPD DD statement, we got this response - > > READY > PING INETSD01.BOULDER.IBM.COM > CS V1R7: Pinging host INETSD01.BOULDER.IBM.COM (207.25.253.62) > READY > END > Unable to open RAW socket: EDC5139I Operation not permitted. -- 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
Re: Receive Order Error
For the record, I would like to correct what I had written earlier regarding this topic. COMMONSEARCH has little or more likely nothing to do with the problem. However, the RESOLVER function of TCP/IP can provide a resolution to the problem. You can choose to put appropriate default values in the DEFAULTTCPIPDATA location as pointed to by the RESOLVER function. These values would become "last resort" values unless overridden by the other search order values. For example, on my system, the IBM default last resort location TCPIP.TCPIP.DATA does not exist. When I run with no RESOLVER DEFAULTTCPIPDATA set, and I run a job which does not specify SYSTCPD DD, then my job which does a PING (MVS API) or TSO command FTP (z/OS UNIX API) fails. You can test this in a similar way that I did. RESOLVER is probably already running on your system. First, find out what RESOLVER is configured to do: F RESOLVER,DISPLAY EZZ9298I DEFAULTTCPIPDATA - None EZZ9298I GLOBALTCPIPDATA - None EZZ9298I DEFAULTIPNODES - None EZZ9298I GLOBALIPNODES - None EZZ9304I NOCOMMONSEARCH EZZ9293I DISPLAY COMMAND PROCESSED This is what I started with. Then, you can create two files - one with RESOLVER parms (I started with one line): In /etc/setup.resolver: DEFAULTTCPIPDATA(/etc/defaulttcpip.data) The second file is /etc/defaulttcpip.data and looks something like this (use the settings in *your* SYSTCPD DD file as your starting point for defining site wide defaults): TCPIPJOBNAME TCPIPMVS DATASETPREFIX your.prefix.TCPIP DOMAINORIGIN yourco.com NSINTERADDR xx.xx.xx.xx NSINTERADDR yy.yy.yy.yy RESOLVEVIA UDP RESOLVERTIMEOUT 30 RESOLVERUDPRETRIES 1 Then, the following to activate: F RESOLVER,REFRESH,SETUP='/etc/setup.resolver' EZZ9298I DEFAULTTCPIPDATA - /etc/defaulttcpip.data EZZ9298I GLOBALTCPIPDATA - None EZZ9298I DEFAULTIPNODES - None EZZ9298I GLOBALIPNODES - None EZZ9304I NOCOMMONSEARCH EZZ9293I REFRESH COMMAND PROCESSED Make sure the permissions for /etc/defaulttcpip.data are 644 so that everyone can read it. Now, after these changes, standard resolver search for all TCP/IP APIs includes, as a last resort, the values specified in /etc/defaulttcpip.data for all address spaces in your system. To harden these values and have them take effect at the next IPL, create RESOLVER JCL as described in manual z/OS IP Config Guide topic 1.2.5.2 Resolver customization, and in particular, include the following DD statement in the RESOLVER JCL: //SETUP DD PATH='/etc/setup.resolver',PATHOPTS=(ORDONLY) While I certainly apologize to all for my incorrect posts earlier in this thread, I am grateful to this list because I sure learned a lot today about RESOLVER! Brian On Mon, 30 Oct 2006 14:31:18 -0600, Brian Peterson wrote: >Mark, you're absolutely right. I've been looking at the books and they can >set up a global search order using the RESOLVER function of TCP/IP. That >way, every address space would get the right set of TCPIP.DATA values, no >matter what they happened to specify. > >According to the books, one of the defaults within RESOLVER is >NOCOMMONSEARCH. Apparently, setting this to COMMONSEARCH allows the >installation to move away from the so-called "standard search order" and >instead have one place to define their TCPIP.DATA parameters. I use the >phrase "so-called" because the "standard search order" is ugly and hard to >understand (in my opinion) because it reflects the evolution of TCP/IP on >z/OS - based upon the API used, a totally different "standard search order" >for TCPIP.DATA parameters applies. COMMONSEARCH overcomes this by imposing >a new site-wide value. > >At least, that's what I've learned so far. Now, I'm off to try it! > >Brian > >On Mon, 30 Oct 2006 11:22:10 -0800, Gibbons, Mark wrote: > >>As far as I can tell. Internet retrieval creates and uses a unix process >in another address space to retrieve orders. The systcpd dd statement is >not passed to the new address space. The only method I've found that works >is to have the data be found in the standard tcp search order. I'm not >sure what the standard search order is (tcp config reference lookup a while >back) but it will find: >> >> userid.TCPIP.DATA >> SYS1.TCPPARMS(TCPDATA) >> something in /etc/ >> >>IBM needs to let us specify this data for the receive. Much like they do >the other information for client and orderserver. I'd be very happy if I >was wrong however. We don't have our tcpd data in the standard search >order. >> >>Mark >> >> >>>>Date:Fri, 27 Oct
Re: Receive Order Error
On Mon, 30 Oct 2006 11:22:10 -0800, Gibbons, Mark <[EMAIL PROTECTED]> wrote: >... The only method I've found that works is to have the data be found > in the standard tcp search order. I'm not sure what the standard search > order is (tcp config reference lookup a while back) but it will find: > > userid.TCPIP.DATA > SYS1.TCPPARMS(TCPDATA) > something in /etc/ > >... However, this may be prohibitted by RESOLVER configuration statement GLOBALTCPIPDATA which will force a set of non-overridable TCPDATA defs. The stack will still go through that "standard" search, but anything trying to override the values in the GLOBALTCPIPDATA dataset will be ignored. And if you supply a GLOBALTCPIPDATA, RESOLVER configuration defs *must* be included there or they will take the IBM defaults. Those non- overridable statements are DomainOrigin/Domain NSInterAddr/NameServer NSPortAddr – ResolveVia ResolverTimeOut ResolverUDPRetries Search SortList If GLOBALTCPIPDATA is included in your implementation, there is no way to override the list of name servers. And if LOOKUP DNS is also included in GLOBALTCPIPDATA your local host files will not be read. (Most shops will probably have the default LOOKUP DNS LOCAL which uses the host files if the search of name servers was unproductive.) Pat O'Keefe -- 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
Re: Receive Order Error
Mark, you're absolutely right. I've been looking at the books and they can set up a global search order using the RESOLVER function of TCP/IP. That way, every address space would get the right set of TCPIP.DATA values, no matter what they happened to specify. According to the books, one of the defaults within RESOLVER is NOCOMMONSEARCH. Apparently, setting this to COMMONSEARCH allows the installation to move away from the so-called "standard search order" and instead have one place to define their TCPIP.DATA parameters. I use the phrase "so-called" because the "standard search order" is ugly and hard to understand (in my opinion) because it reflects the evolution of TCP/IP on z/OS - based upon the API used, a totally different "standard search order" for TCPIP.DATA parameters applies. COMMONSEARCH overcomes this by imposing a new site-wide value. At least, that's what I've learned so far. Now, I'm off to try it! Brian On Mon, 30 Oct 2006 11:22:10 -0800, Gibbons, Mark wrote: >As far as I can tell. Internet retrieval creates and uses a unix process in another address space to retrieve orders. The systcpd dd statement is not passed to the new address space. The only method I've found that works is to have the data be found in the standard tcp search order. I'm not sure what the standard search order is (tcp config reference lookup a while back) but it will find: > > userid.TCPIP.DATA > SYS1.TCPPARMS(TCPDATA) > something in /etc/ > >IBM needs to let us specify this data for the receive. Much like they do the other information for client and orderserver. I'd be very happy if I was wrong however. We don't have our tcpd data in the standard search order. > >Mark > > >>>Date:Fri, 27 Oct 2006 15:33:02 -0500 >>>From:Brian Peterson >>>Subject: Re: Receive Order Error > >>>OK - This result shows that the SYSTCPD DD statement is required for your >>>RECEIVE job, and should fix your problem where RECEIVE is unable to resolve >>>the inetsd01.boulder.ibm.com address - the "unknown host" error. > >0:04 -0500, Dick Renneke wrote: > >>With the SYSTCPD DD statement, we got this response - >> > >-- >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 >= -- 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
Re: Receive Order Error
As far as I can tell. Internet retrieval creates and uses a unix process in another address space to retrieve orders. The systcpd dd statement is not passed to the new address space. The only method I've found that works is to have the data be found in the standard tcp search order. I'm not sure what the standard search order is (tcp config reference lookup a while back) but it will find: userid.TCPIP.DATA SYS1.TCPPARMS(TCPDATA) something in /etc/ IBM needs to let us specify this data for the receive. Much like they do the other information for client and orderserver. I'd be very happy if I was wrong however. We don't have our tcpd data in the standard search order. Mark >>Date:Fri, 27 Oct 2006 15:33:02 -0500 >>From:=?iso-8859-1?Q?Brian_Peterson?= <[EMAIL PROTECTED]> >>Subject: Re: Receive Order Error >>OK - This result shows that the SYSTCPD DD statement is required for your >>RECEIVE job, and should fix your problem where RECEIVE is unable to resolve >>the inetsd01.boulder.ibm.com address - the "unknown host" error. 0:04 -0500, Dick Renneke wrote: >With the SYSTCPD DD statement, we got this response - > -- 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
Re: Receive Order Error
OK - This result shows that the SYSTCPD DD statement is required for your RECEIVE job, and should fix your problem where RECEIVE is unable to resolve the inetsd01.boulder.ibm.com address - the "unknown host" error. So, if you add SYSTCPD to your RECEIVE job, you should expect to get some result OTHER than: >SC0508 initConnection: Calling getaddrinfo() with inetsd01.boulder.ibm.com >SC0517 initConnection: getaddrinfo() resptr 0 rc 1/EDC9501I The name does >not re >solve for the supplied parameters. (errno2=0x112B) >Unknown host: inetsd01.boulder.ibm.com Again, I'm not saying this will fix every problem and make the RECEIVE job work. It is a required first step. You first must be able to resolve via DNS the IP address of inetsd01.boulder.ibm.com before your RECEIVE job will attempt to connect from your system to that host - via whatever obstacles your network implementation imposes (proxys, firewalls, etc). Once SMP/E attempts to connect to the IBM host, then the issues of proxy or firewall come into play. Brian On Fri, 27 Oct 2006 14:50:04 -0500, Dick Renneke wrote: >With the SYSTCPD DD statement, we got this response - > >READY > PING INETSD01.BOULDER.IBM.COM >CS V1R7: Pinging host INETSD01.BOULDER.IBM.COM (207.25.253.62) >READY >END >Unable to open RAW socket: EDC5139I Operation not permitted. > > -- 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
Re: Receive Order Error
With the SYSTCPD DD statement, we got this response -
READY
PING INETSD01.BOULDER.IBM.COM
CS V1R7: Pinging host INETSD01.BOULDER.IBM.COM (207.25.253.62)
READY
END
Unable to open RAW socket: EDC5139I Operation not permitted.
Brian Peterson
IBM-MAIN@BAMA.UA.EDU
Sent by: IBM cc
Mainframe
Discussion List Topic
<[EMAIL PROTECTED]
.EDU> Subject
Re: Receive Order Error
10/27/2006 01:21
PM
Please respond to
IBM Mainframe
Discussion List
<[EMAIL PROTECTED]
.EDU>
Simplify. Makes problem determination easier.
What happened when you ran the PING test?
Brian
On Fri, 27 Oct 2006 10:44:44 -0500, Dick Renneke <[EMAIL PROTECTED]>
wrote:
>We added the SYSTCPD DD statement to the SMPE job but got the same
>messages.
>
>SC0508 initConnection: Calling getaddrinfo() with inetsd01.boulder.ibm.com
>SC0517 initConnection: getaddrinfo() resptr 0 rc 1/EDC9501I The name does
>not re
>solve for the supplied parameters. (errno2=0x112B)
>Unknown host: inetsd01.boulder.ibm.com
>
>Do you use the FIREWALL statement or when is it needed?
>
>Dick
>
--
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
--
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
Re: Receive Order Error
Simplify. Makes problem determination easier. What happened when you ran the PING test? Brian On Fri, 27 Oct 2006 10:44:44 -0500, Dick Renneke <[EMAIL PROTECTED]> wrote: >We added the SYSTCPD DD statement to the SMPE job but got the same >messages. > >SC0508 initConnection: Calling getaddrinfo() with inetsd01.boulder.ibm.com >SC0517 initConnection: getaddrinfo() resptr 0 rc 1/EDC9501I The name does >not re >solve for the supplied parameters. (errno2=0x112B) >Unknown host: inetsd01.boulder.ibm.com > >Do you use the FIREWALL statement or when is it needed? > >Dick > -- 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
Re: Receive Order Error
We added the SYSTCPD DD statement to the SMPE job but got the same messages. SC0508 initConnection: Calling getaddrinfo() with inetsd01.boulder.ibm.com SC0517 initConnection: getaddrinfo() resptr 0 rc 1/EDC9501I The name does not re solve for the supplied parameters. (errno2=0x112B) Unknown host: inetsd01.boulder.ibm.com Do you use the FIREWALL statement or when is it needed? Dick -- 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
Re: Receive Order Error
Aha - that's the problem. Make sure that batch jobs such as your SMP/E RECEIVE command job include a valid DNS hierarchy. As is often the case, there's a bunch of different ways to specify this, but one way, which I use on my system, is to code a SYSTCPD DD statement, pointing to a parameter file with the following statements: NSINTERADDR x.x.x.x NSINTERADDR y.y.y.y You should be able to validate this by the following JCL: //S1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTCPD DD DSN=tcpip.data,DISP=SHR //SYSTSIN DD * ping inetsd01.boulder.ibm.com /* If I run this job and omit the SYSTCPD, I get the following: READY ping inetsd01.boulder.ibm.com EZZ3111I Unknown host 'INETSD01.BOULDER.IBM.COM' READY END If I run this job with my valid SYSTCPD, I get the following: READY ping inetsd01.boulder.ibm.com CS V1R7: Pinging host INETSD01.BOULDER.IBM.COM (207.25.253.62) Ping #1 timed out READY END That's why I think your problem is a bad SYSTCPD NSINTERADDR value. Brian On Fri, 27 Oct 2006 08:36:00 -0500, Dick Renneke <[EMAIL PROTECTED]> wrote: >The other message that we see are - > (snip) >SC0508 initConnection: Calling getaddrinfo() with inetsd01.boulder.ibm.com >SC0517 initConnection: getaddrinfo() resptr 0 rc 1/EDC9501I The name does >not re >solve for the supplied parameters. (errno2=0x112B) >Unknown host: inetsd01.boulder.ibm.com (snip) -- 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
Re: Receive Order Error
The other message that we see are - CY1178 ftpStart: client operating in IPv4 only mode CZ0251 ftpOpen: entered SC0432 initConnection: entered SC0508 initConnection: Calling getaddrinfo() with inetsd01.boulder.ibm.com SC0517 initConnection: getaddrinfo() resptr 0 rc 1/EDC9501I The name does not re solve for the supplied parameters. (errno2=0x112B) Unknown host: inetsd01.boulder.ibm.com We thought that the error was related to our FIREWALL so we added a FIREWALL statement. It did not help. We are not sure if our FIREWALL statement is correct. -- 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
Re: Receive Order Error
Well, for dumbsorry about my previous reply. I ran debug="yes" myself, and discovered that... CY1170 ftpStart: socket() failed on AF_INET6 - EDC8114I Address family not supported. (errno2=0x11B3005A) ...is a normal message. Your "real" error must have come later. >From my debug="yes" run, here's the next few messages: CY1178 ftpStart: client operating in IPv4 only mode CZ0251 ftpOpen: entered SC0432 initConnection: entered SC0508 initConnection: Calling getaddrinfo() with inetsd01.boulder.ibm.com SC0527 initConnection: getaddrinfo() returned. SC0689 initNamedConnection: entered SC0850 initIPv4Connection: entered CY2765 access_via_socks_server: entered Connecting to: inetsd01.boulder.ibm.com 207.25.253.62 port: 21. Brian On Thu, 26 Oct 2006 17:14:41 -0500, Brian Peterson wrote: >You might try turning on FTP debugging to gather more information about the >error. > >This is specified in the CLIENT data set. For example: > >* Top of Data * > debug="yes" >javahome="/usr/lpp/java/J1.4" >classpath="/usr/lpp/smp/classes" >javadebugoptions="-Dcom.ibm.smp.debug=severe -showversion"> > host="proxy.mycompany.com" > port="8080"> > > > Bottom of Data *** > >The other thing I noticed that looked a bit odd was that your error message >mentioned AF_INET6. Do you really intend to use IPV6? > >Brian > >On Thu, 26 Oct 2006 14:31:24 -0500, Dick Renneke wrote: > >>We are trying to setup our RECEIVE ORDER process on z/OS 1.7. We have not >>used RECEIVE ORDER before and need some help. We are getting the following >>messages - >> >>GIM68700IORDER ORD6 HAS BEEN SENT TO THE SERVER AT >> https://207.25.252.197/services/projects/ecc/ws/. >>GIM69144IORDER ORD6 IS READY FOR DOWNLOAD. >>GIM46200S ** RECEIVE PROCESSING HAS FAILED BECAUSE THERE WAS AN FTP ERROR. >> >>CY1170 ftpStart: socket() failed on AF_INET6 - EDC8114I Address family not >>supported. (errno2=0x112B) >> > >-- >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 -- 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
Re: Receive Order Error
You might try turning on FTP debugging to gather more information about the error. This is specified in the CLIENT data set. For example: * Top of Data * Bottom of Data *** The other thing I noticed that looked a bit odd was that your error message mentioned AF_INET6. Do you really intend to use IPV6? Brian On Thu, 26 Oct 2006 14:31:24 -0500, Dick Renneke wrote: >We are trying to setup our RECEIVE ORDER process on z/OS 1.7. We have not >used RECEIVE ORDER before and need some help. We are getting the following >messages - > >GIM68700IORDER ORD6 HAS BEEN SENT TO THE SERVER AT > https://207.25.252.197/services/projects/ecc/ws/. >GIM69144IORDER ORD6 IS READY FOR DOWNLOAD. >GIM46200S ** RECEIVE PROCESSING HAS FAILED BECAUSE THERE WAS AN FTP ERROR. > >CY1170 ftpStart: socket() failed on AF_INET6 - EDC8114I Address family not >supported. (errno2=0x112B) > -- 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
