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
