Is localhost defined? Sent from my iPad
> On Jun 8, 2020, at 8:16 AM, Sean Gleann <sean.gle...@gmail.com> wrote: > > Thanks for the hint about thoroughly checking output, Michael. > I went back and studied all the saved outputs, hoping to find something > that might be helpful. > In the event, there were no indications of such problems - no error > messages or non-zero return codes - but it's as well to be sure. > > Can I ask you for more information regarding what you see with the '3.2 > Retrieve Workflow version' step, please? > For me, I get to the point of clicking 'Perform' on this step, and I see > that z/OSMF is about to use the REST API with the request > > https://localhost:10443/zosmf/workflow/rest/1.0/workflows/3ca56936-9a81-48a0-94d9-84e28ee2d842 > : > > Clicking 'Next' on this results in: > > IZUWF9999E: The request cannot be completed because an error occurred. The > following error data is returned: "EDC8128I Connection refused. > (errno2=0x76630291) (Connection refused)" > > and so I am forced to click on 'Finish' if I am to proceed. > What do you see during this sequence? > > I suspect that it's the 'localhost:10443' bit that is the root of the > problem, but I'm unsure how to circumvent it, or even to correct the > problem. > As I said earlier in this thread, I'm working through a tunnelled SSH > connection to access my z/OSMF. In the main, this is working quite happily. > That connection definition associates my desktop system's local port 10443 > with the hosts systems' 10443, and the URL I use to access z/OSMF is > https://localhost:10443/zosmf. > So I'm at a bit of a loss in understanding why the connection should be > refused. > > Regards > Sean > > >> On Fri, 5 Jun 2020 at 04:08, Michael Babcock <bigironp...@gmail.com> wrote: >> >> Oh and beware, just because the Verify Feature Bits job (and a couple of >> others) gets a zero condition code doesn’t mean it executed successfully. >> You have to check STDERR and STDOUT tabs. Mine always gets a syntax >> error. >> >>> On Thu, Jun 4, 2020 at 10:05 AM Sean Gleann <sean.gle...@gmail.com> wrote: >>> >>> It's been really quite a troublesome effort for me, Michael, but I guess >>> it's true to say that most of the problems are down to my rudimentary >>> knowledge of TCPIP and networking in general. >>> For various reasons, I have to use a tunnelled connection through to the >>> z/OS guest, and that makes things a bit more interesting. >>> The 'Getting Started' redbook (SG24-8457-00) has been my sole point of >>> reference all the way through, and yeah, it's OK - up to point. it >> doesn't >>> cover the tunnelling complication, naturally, and there are some very >> poor >>> typos to take into account. >>> As for the Workload Provisioning process in z/OSMF - after you've >> specified >>> a bunch of parameters, it's just a JCL generator/job submitter/checker >> with >>> a couple of z/OSMF-specific bits thrown in. >>> During the initial parameter specification phase I had considerable >>> difficulty at the point of specifying the RSA key, but eventually got it >>> right. >>> Step 3.2 in the process - where some sort of version information is >> looked >>> for - has always failed for me. I've never been able to make it work as >>> expected and have had to force it to a 'complete' state by clicking the >>> 'Finish' button. >>> >>> I tried to adapt the process detailed in the redbook to suit our security >>> set-up, but the result never worked. In the end, I followed the procedure >>> to the letter, and created the ZCXxxx users and groups in RACF as >>> specified. >>> Result - I've finally got a working container that I can log in to. The >>> next step according to the redbook is to download an image from >>> hub.docker.com, but when I try the specified command - 'docker pull >> nginx' >>> - the container tries to go to registry-1.docker/.io/v2 - which isn't >>> specified anywhere in the parameter files created by z/OSMF - and it >> times >>> out. >>> I've added suitable mods to \etc\hosts, \etc\ipnodes and to TCPIP.HOSTS, >>> messed around with DNS specifications and I've commented out the IPSEC >>> statements in the TCPIP PROFILE parameters (thank gawd for sandbox >>> systems!). Nothing along those lines has altered the situation. >>> Now, I'm waiting for our company networking guys to suggest other things >> to >>> try. >>> >>> Good luck with your efforts, Michael. >>> I hope you have a smoother ride than I have had so far. >>> >>> Sean >>> >>> On Thu, 4 Jun 2020 at 15:32, Michael Babcock <bigironp...@gmail.com> >>> wrote: >>> >>>> Sean, >>>> >>>> I’m just going through the provisioning process now. Any gotchas that >>> you >>>> care to share? >>>> >>>> On Thu, Jun 4, 2020 at 5:30 AM Sean Gleann <sean.gle...@gmail.com> >>> wrote: >>>> >>>>> Thanks, Gadi. >>>>> Yes, there are GLZ messages associated with these AZDs, but all they >> do >>>> is >>>>> identify the stored failure data. >>>>> >>>>> It's all somewhat moot now. I tried to /P the container, and got told >>> the >>>>> task was non-cancellable. >>>>> Eventually I resorted to a FORCE ARM to get rid of it. >>>>> Restarted the task and now it's running perfectly! No errors or >>> warnings, >>>>> and I'm logged in, ready to start working with my first container. >>>>> >>>>> Sean >>>>> >>>>> On Thu, 4 Jun 2020 at 11:12, Gadi Ben-Avi <gad...@malam.com> wrote: >>>>> >>>>>> I found this: >>>>>> >>>>>> >>>>> >>>> >>> >> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.izso100/izso100_diagnosisservice.htm >>>>>> >>>>>> It looks like the real information is in GLZ messages. >>>>>> >>>>>> I don't have z/OS v2.4 running, so I can't really check. >>>>>> >>>>>> Gadi >>>>>> >>>>>> -----Original Message----- >>>>>> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On >>>> Behalf >>>>>> Of Sean Gleann >>>>>> Sent: Thursday, June 4, 2020 12:53 PM >>>>>> To: IBM-MAIN@LISTSERV.UA.EDU >>>>>> Subject: AZD messages? >>>>>> >>>>>> Can anyone point me at documentation for AZD... messages coming out >>> of >>>> a >>>>>> zcx container, please? >>>>>> >>>>>> I'm getting: >>>>>> AZDN0004E Failure &rsn configuring IPv4 address and AZDP0001E >>>> Unexpected >>>>>> error 5 configuring data disks >>>>>> >>>>>> but various attempts at searching for these produce 'nothing found' >>>>>> responses. >>>>>> >>>>>> Regards >>>>>> Sean >>>>>> >>>>>> >>> ---------------------------------------------------------------------- >>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >> send >>>>> email >>>>>> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>>>>> >>>>>> Email secured by Check Point >>>>>> >>>>>> >>> ---------------------------------------------------------------------- >>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>>> send email to lists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >>>>>> >>>>> >>>>> >> ---------------------------------------------------------------------- >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email to lists...@listserv.ua.edu with the message: INFO >> IBM-MAIN >>>>> >>>> -- >>>> Michael Babcock >>>> OneMain Financial >>>> z/OS Systems Programmer, Lead >>>> >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>>> >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >> -- >> Michael Babcock >> OneMain Financial >> z/OS Systems Programmer, Lead >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
