That's great news, Michael!! I managed to finally(!) get that step3.2 to run successfully at the end of yesterday. I'm seeing pretty much the same sort of info as you are seeing. Have spent today de-provisioning the existing container and going through the provisioning process once more Will see what tomorrow brings...
Regards Sean On Tue, 9 Jun 2020 at 18:59, Michael Babcock <bigironp...@gmail.com> wrote: > Sean, > > Good News! I successfully started a zCX instance and logged on via OMVS > and used the ssh command to reach the zCX instance. I also successfully > logged on via a Bluezone VT320 session pointing to our DVIPA address. I > had to transfer the admin IDs private key to my PC, convert it to ppk > format (using Puttygen) and import that in Bluezone’s session. Woohoo! > > For the “Retrieve Workflow Version” step (3.2) Here’s the request tab > (I’ve obscured certain details, like https://mysystem.mycompany, etc). > > HTTP method: > GET > Request: > > https://mysystem.mycompany:43200/zosmf/workflow/rest/1.0/workflows/d17d4bf9-4467-41b7-8e6c-ec8d47c40997 > > And this is what I get in the Response tab. Also don’t forget, in the > Status tab, the expected return code is 200, my actual return is 200. > > > { > "access": "Public", > "accountInfo": null, > "automationStatus": null, > "category": "provisioning", > "containsParallelSteps": false, > "deleteCompletedJobs": false, > "globalVariableGroup": null, > "isCallable": null, > "jobStatement": null, > "owner": "xxxx", > "percentComplete": 9, > "productID": "HZDC7C0", > "productName": "IBM z\/OS Container Extensions", > "productVersion": "V2R4.1.0", > "scope": "none", > "softwareType": "IBM-zCX", > "statusName": "in-progress", > "system": "mySplex.mySystem", > "vendor": "IBM", > "workflowDefinitionFileMD5Value": "11b08002b4648a0778c35c76dcbe9f64", > "workflowDescription": "Provision a IBM zOS Container Extensions > Appliance Instance.", > "workflowID": "zOS_Container_Extensions_Provision", > "workflowKey": "d17d4bf9-4467-41b7-8e6c-ec8d47c40997", > "workflowName": "Provision a IBM zOS Container Extensions Appliance > Instance. - Workflow", > "workflowVersion": "1.0.18" > } > > On 6/8/2020 7:16 AM, Sean Gleann 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
