As far as I understand things, 'localhost' is just another way of saying '127.0.0.1' meaning 'this computer', so - yes, localhost is defined. I have an SSH connection defined in PuTTY that associates my local 10443 with the host system's 10443, and I start that connection before attempting to go to https://localhost:10443 in my browser (Opera). I'm quite happy to be shown any error in my understanding, however.
But you've sparked off another train of thought, Lloyd. Whilst it's true I get to my z/OSMF with 'https://localhost:10443/zosmf', the very first thing I see is a warning that the connection is not secure and I have to click on 'continue anyway' in order to get to the z/OSMF sign-on screen. I think I've got to sort out *that* problem before trying to go any further. Regards Sean , On Mon, 8 Jun 2020 at 13:55, Lloyd Fuller <[email protected]> wrote: > Is localhost defined? > > Sent from my iPad > > > On Jun 8, 2020, at 8:16 AM, Sean Gleann <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >>> 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 <[email protected]> > >>> 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 <[email protected]> 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 <[email protected]> On > >>>> Behalf > >>>>>> Of Sean Gleann > >>>>>> Sent: Thursday, June 4, 2020 12:53 PM > >>>>>> To: [email protected] > >>>>>> 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 [email protected] with the message: INFO IBM-MAIN > >>>>>> > >>>>>> Email secured by Check Point > >>>>>> > >>>>>> > >>> ---------------------------------------------------------------------- > >>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>>>> send email to [email protected] with the message: INFO > >>> IBM-MAIN > >>>>>> > >>>>> > >>>>> > >> ---------------------------------------------------------------------- > >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>>> send email to [email protected] 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 [email protected] with the message: INFO > IBM-MAIN > >>>> > >>> > >>> ---------------------------------------------------------------------- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to [email protected] 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 [email protected] with the message: INFO IBM-MAIN > >> > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
