hi Mike Your partially right. The tech support people want to access the hmc remotely because they are located almost 80 kilometres from the datacenter so that makes sense.
The zBC12 and the Z14 sit alongside each other in the DR datacenter. Both are on the same LAN segment and subnet. However if they cannot even access the hmc locally in the same LAN segment the remote access is not really an issue. I'm not a technical person in this area but I think the goal is to somehow replicate the settings from the z12 hmc to the z14 since we basically want to maintain the same iocds LPAR configuration logon credentials etc. There seems to be a reluctance to use a USB drive because they want all the HMC's on the network to replicate credentials and settings from more one master copy. Using a USB drive would bypass that process. But it was certainly allow us to get the new Z 14 up and running. They are in the datacenter again today and I have not had an update so far. But should they still encounter connection problems who is this Top Gun Z you speak of? On Mon, Mar 25, 2019, 5:08 AM Mike Smith <mike.sm...@nasrp.com> wrote: > Laurence, thanks for the earlier clarification. > > Just to make sure that I understand.... At this point, the zBC12 and the > ZR1 are sitting in the DR site, each with their own HMC (on the same > network). Right? If so I'd hazard a guess that the desire to do everything > remotely is because there is no technical staff at the DR site. > > Absolutely the easiest way to transfer the LPAR definitions, user info, > OSA ICC definitions and I/O definitions is via a USB drive The SSR > frequently does this as part of the install. (The SSR must do this if the > customer choses to replace the old HMC with the new HMC). Since the SSR > knows how to do it, I'd reach out to the SSR and see if he could copy these > definitions across for you. Alternately, if there is any staff at the DR > site, could someone insert a USB drive into the zBC12 HMC? Then the > information could be copied to the USB drive (via commands issued > remotely). Then a local staff person could move the USB drive to the new > HMC. Again, the information could be copied (imported in this case) via > commands issued remotely. Data transfer complete. > > If it is absolutely imperative that the two HMCs talk to each other, then > I recommend that you open a HW incident on the z14 to engage the SSR, then > ask him to involve the z Top Gun. > > I am curious about the process your technical team wants to follow to > transfer this information. Coul you obtain a copy of that process and > document it here? > > Regards, > > Mike > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Laurence Chiu > Sent: Saturday, March 23, 2019 12:18 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Remote access to Z14 ZR1 Support Element via HMC question > > Out of interest how did you copy the data from the old hmcs to the new > ones? I'm not sure my post got to the list but the approach our tech > people are using is to use the HMC for the 12 to populate the HMCs for the > 14 and so far the old HMC cannot discover the new one. That is a potential > show stopper for us. > > On Sun, Mar 24, 2019, 4:19 AM Jesse 1 Robinson <jesse1.robin...@sce.com> > wrote: > > > We replaced two z12s late last year with a z14 and a z13s. I didn't do > the > > actual work, but all 'migratable' HMC data was copied over to the new > CECs > > ahead of the push-pull swap out. This includes profile data and > > userids/passwords. The z14 includes some new options that need to be set > > manually because they don't have counterparts on the z12, but before the > > swap, all four CECs were able to communicate with each other. > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Parwez > > Sent: Saturday, March 23, 2019 3:25 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: Remote access to Z14 ZR1 Support Element via HMC > > question > > > > Just a thought. > > > > Although its possible to use some of the older HMC H/W (I think its FC > > 0092 - zBC12 had this and FC 0095), even with the correct level of HMC > > code, these do not support some of the HMC Enhancements (GA2) which were > > delivered with System Driver level 36 and HMC/SE Level 2.14.1 > > > > Parwez > > > > ________________________________ > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > > of Laurence Chiu <lch...@gmail.com> > > Sent: 21 March 2019 18:45 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Remote access to Z14 ZR1 Support Element via HMC question > > > > Thanks > > > > We did do a major HMC firmware upgrade across the complex recently and > > that issue was checked during our diagnostic call but all HMCs are on the > > same level. > > > > Hopefully it's the domain issue else will be at our wits end. For some > > reason our support organisation does not want to copy the zBC12 > > configuration information across to the new z14 using a USB drive but > > really want the HMC for the zBC12 to connect to the z14 so the > > configuration information is already loaded. > > > > On Thu, Mar 21, 2019, 8:07 PM Parwez <parwez_ha...@hotmail.com> wrote: > > > > > While I can't answer your specific Q. A general point - a HMC with > > 'lower' > > > level of HMC code can't control/access System requiring a 'higher' > > > level of HMC code. A HMC with higher level code e.g the z14 ZR1 HMC > > > can access/control Systems all the way back to z10 EC and BC. If your > > > zBC12 HMC is at level 2.12.1 then this could be the issue. If your > > > zBC12 HMC hardware is of the right spec, then there is nothing to stop > > > you upgrading it to the same level code as the z14 ZR1 HMC. > > > > > > Regards > > > Parwez > > > > > > ________________________________ > > > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on > > > behalf of Laurence Chiu <lch...@gmail.com> > > > Sent: 21 March 2019 06:07 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Remote access to Z14 ZR1 Support Element via HMC question > > > > > > OK an update. We haven't solved the remote access issue yet but the > > > guys wanted to do use the zBC12 HMC to discover the Z14 HMC. But > > > despite all networking being fine (all the HMC's and the SE's are in > > > the same LAN > > > segment) the zBC12 HMC could not see the Z14 HMC. Yet if they logged > > > onto the Z14 HMC it could see the Z14 SE fine. I asked the question > > > (since one of my colleagues has done this before) since the new > > > machine is a drop-in replacement using the same DS8K SAN, why don't > > > they just copy the config from the zBC12 HMC to a USB drive and load > > > it onto the Z14. I was told that wasn't standard practice, even though > > it would work. > > > > > > Further diagnosis reveals a potential issue with the domain settings on > > the > > > new HMC's and SE's not matching those on the existing ones. The new > > HMC's > > > were setup with domain defaults I am told and they are probably not > > > what the old HMC's were setup with. Something along the lines of " > > > The “Current domain name” is displayed on the window. If NOT SET is > > > displayed, it indicates that default domain security is in effect for > > > this console." This is from the Hardware Management Console Operations > > > Guide - Version 2.14.0 > > > > > > http://www-01.ibm.com/support/docview.wss?uid=isg23e9d1b6de8c163f98525 > > > 8195006801cc > > > pages 712 onwards > > > > > > Now if the existing HMC's have an actual domain name setting in them, > > > then it make sense they cannot connect to a HMC with default domain > > > security since there is a mismatch. > > > > > > That apparently is our next diagnostic step. Just wonder if other > > > folks on this list have ever encountered problems similar to this? > > > Thanks > > > > > > On Thu, Mar 21, 2019 at 2:55 PM Laurence Chiu <lch...@gmail.com> > wrote: > > > > > > > Thanks > > > > > > > > Looking at this list and the firewall requests that have been > > > > raised, it seems we're covered. > > > > > > > > Interesting as noted we have a zBC12 in the same room and there is > > > > no problem accessing it and the new HMC'S for the z14 are in the > > > > same subnet so should be covered by the same firewall rules. > > > > > > > > However nobody can tell if they've ever tried to access the SE on > > > > the > > > > zBC12 remotely because as another poster said, if your configuration > > > > is stable then there is little need to do that. > > > > > > > > That could certainly point to a firewall rule that's never been > tested. > > > > > > > > Again back to my original point, why can't the support element > > > > configuration be done locally why we try to figure out the network > > > > issues for remote access > > > > > > > > > > > > > > > > On Thu, Mar 21, 2019, 3:10 AM Edgington, Jerry < > > > > jerry.edging...@westernsouthernlife.com> wrote: > > > > > > > >> Dana, > > > >> > > > >> Here is my "cheat sheet" for HMC ports and direction. However, I > > > >> don't know if they have changed for z14 ZR1, but they work for z13s. > > > >> > > > >> ○ HMC inbound IP ports from internal network > > > >> § Type Source Port Usage > > > >> ICMP 8 Establish communication with > > > >> resources managed by HMC > > > >> TCP 58787 - 58788 Automatic discovery > of > > > >> zServers > > > >> UDP 58788 Automatic discovery of > > zServers > > > >> UDP 9900 HMC to HMC auto discovery > > > >> TCP 55555 SSL communication from > servers > > > >> TCP 9920 SSL HMC and zServers > > > >> TCP 443 Remote user access to HMC > > > >> TCP 9950-9959 Proxy Single Object > > > >> Operations to server > > > >> TCP 9960 Java applet-based tasks (not > > > >> required since v2.12.1) > > > >> UDP 161 SMNP automation of the HMC > > > >> TCP 161 SMNP automation of the HMC > > > >> TCP 3161 SMNP automation of the HMC > > > >> TCP 6794 SSL automation traffic, > > > including > > > >> HMC Mobile app > > > >> TCP 61612 Web Services API message > > broker, > > > >> flowing STOMP > > > >> TCP 61617 Web Services API message > > broker, > > > >> flowing OpenWire > > > >> UDP 123 Set the time of the servers > > > >> UDP 520 Communications with routers > > from > > > >> HMC > > > >> TCP 22 Remote access by Product > > > >> Engineering > > > >> TCP 21 Inbound FTP requests > > > >> TCP 3900-3909 AMM for zBX > > > >> > > > >> > > > >> ○ HMC outbound IP ports to network to internal > network > > > >> Type Source Port Usage > > > >> ICMP 8 Establish communication with > > > >> resources managed by HMC > > > >> UDP 9900 HMC to HMC auto discovery > > > >> TCP 58787 - 58788 Automatic discovery > of > > > >> zServers > > > >> UDP 58788 Automatic discovery of > > zServers > > > >> TCP 55555 SSL communication from > servers > > > >> TCP 9920 SSL HMC and zServers > > > >> TCP 443 Single Object Operations to > > > >> server console > > > >> TCP 9960 Java applet-based tasks (not > > > >> required since v2.12.1) > > > >> TCP 25345 Single Object Operations to > > > >> server console > > > >> TCP X LDAP port to authenticate > > Users > > > >> TCP 443 Call home requests RSF, and > > HMC > > > >> mobile app > > > >> TCP 3900 AAM for zBX > > > >> TCP 21 Load system software or > > utility > > > >> programs > > > >> TCP 22 SSH > > > >> UDP 123 Connect to NTP server > > > >> TCP 25 SMTP for email > > > >> > > > >> ○ SE inbound IP ports from internal network > > > >> § Type Source Port Usage > > > >> ICMP 8 Establish communication with > > > >> resources managed by HMC > > > >> TCP 58787 Automatic discovery of > > zServers > > > >> UDP 58787 Automatic discovery of > > zServers > > > >> TCP 55555 SSL communication from > servers > > > >> TCP 9920 SSL HMC and zServers > > > >> TCP 443 Call home requests RSF, and > > HMC > > > >> mobile app > > > >> TCP 9950-9959 Manage DataPower > XI50z > > > >> from HMC > > > >> TCP 9960 Java applet-based tasks (not > > > >> required since v2.12.1) > > > >> UDP 161 SMNP automation of the HMC > > > >> TCP 161 SMNP automation of the HMC > > > >> TCP 3161 SMNP automation of the HMC > > > >> UDP 123 Set the time of the servers > > > >> UDP 520 Communications with routers > > from > > > >> HMC > > > >> TCP 22 Remote access by Product > > > >> Engineering > > > >> TCP 21 Inbound FTP requests > > > >> TCP 3900-3909 AMM for zBX > > > >> > > > >> ○ SE outbound IP ports to internal networks > > > >> § Type Source Port Usage > > > >> ICMP 8 Establish communication with > > > >> resources managed by HMC > > > >> UDP 9900 HMC to HMC auto discovery > > > >> TCP 58787 Automatic discovery of > > zServers > > > >> UDP 58787 Automatic discovery of > > zServers > > > >> TCP 55555 SSL communication from > servers > > > >> TCP 9920 SSL HMC and zServers > > > >> TCP 443 Single Object Operations to > > > >> server console > > > >> TCP 9960 Java applet-based tasks (not > > > >> required since v2.12.1) > > > >> TCP 25345 Single Object Operations to > > > >> server console > > > >> TCP X LDAP port to authenticate > > Users > > > >> TCP 443 Call home requests RSF, and > > HMC > > > >> mobile app > > > >> TCP 3900 AAM for zBX > > > >> TCP 21 Load system software or > > utility > > > >> programs > > > >> TCP 22 SSH > > > >> UDP 520 Communications with routers > > from > > > >> HMC > > > >> UDP 123 Set the time of the servers > > > >> > > > >> -----Original Message----- > > > >> From: IBM Mainframe Discussion List > > > >> [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > > On > > > >> Behalf Of Dana Mitchell > > > >> Sent: Wednesday, March 20, 2019 10:06 AM > > > >> To: IBM-MAIN@LISTSERV.UA.EDU > > > >> Subject: Re: Remote access to Z14 ZR1 Support Element via HMC > > > >> question > > > >> > > > >> As far as firewall rules go, we can access SOO remotely so I'm > > > >> looking back at some of my old firewall requests, and it looks like > > > >> for a new > > > HMC I > > > >> requested ports 443,9960 and 2300 to be opened. But in the current > > > >> doc, port 2300 is not referenced, so I don't recall what that was > for. > > > >> > > > >> Your other question about accessing the SE's, I would say that > > > >> wouldn't be neccessary very much at all once the machine is setup, > > > >> perhaps for > > > CHP > > > >> problem determination type of thing, but I can't think of normal > > > >> day to > > > day > > > >> requirements. > > > >> > > > >> Dana > > > >> > > > >> On Wed, 20 Mar 2019 22:02:21 +1300, Laurence Chiu > > > >> <lch...@gmail.com> > > > >> wrote: > > > >> > > > >> > > > > >> >Any thoughts from the group on this parallel approach. I have no > > > >> >idea how often the SE needs to be accessed but this is a fairly > > > >> >static environment so I would think not that often. > > > > ---------------------------------------------------------------------- > > 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
