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
