Re: Getting rid of a z14 zr1 - any value in the host cards?
I would imagine that the FICON and OSA cards might have value to someone. These cards can still be used in other z14's, z15's and z16's. With the hardware WKFM date for z15's having passed, the only way to add an adapter to a z15 is to acquire it from the secondary market (aka used). You could try posting them on eBay or contact some of the companies that trade in used IBM parts. Good luck! Mike -Original Message- From: IBM Mainframe Discussion List On Behalf Of Laurence Chiu Sent: Friday, February 23, 2024 6:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting rid of a z14 zr1 - any value in the host cards? Sorry. Z14 On Sat, Feb 24, 2024, 2:59 PM Charles Mills wrote: > z14 as in the Subject or z16 as in the body? > > CM > > On Sat, 24 Feb 2024 12:04:39 +1300, Laurence Chiu > wrote: > > >I need to decommission and remove for potential destruction z16 zr1. > >It only has one active engine so it's capped at 88 mips which isn't > >very useful. But for a number of reasons it has a ton of 16G fibre > >channel cards (6 or 8 I think). They might have some value so I was > >thinking I would remove them before having the host removed. There > >are > also > >4 OSA Express cards (10G). Our IBM SE said IBM do not support used > >cards > in > >CEC's but that does not mean they won't work? > > > >Another thought was it could be used as a sysprog play pen, carving > >up > some > >storage of the DS8K we have and creating a small z/OS image. But how > >much play can you do in 88 MIPS? > > -- > 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
Re: EXTERNAL EMAIL: Re: System Programmer Titles
Well, there aren't any IBM CEs anymore. IBM, of course, discontinued the Customer Engineer (CE) title in the U.S. many years ago replacing it with the title of Support Services Representative. Likewise, the old IBM title for a Systems Engineer (SE) changed into such exciting titles such as FTSS (Field Technical Sales Specialist) and CTS (Customer Technical Specialist). These latter changes document the reduction in scope of the SEs job as the focus shifted more and more on sales activities and less on providing support to the client. As to the original question of alternative job titles for Systems Programmers, I'm seeing it becoming more common for the "Most Exalted z/OS Person" (which is one of my suggestions for the job title) is now described as a System Analysist or Mainframe Analysist. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joe Monk Sent: Saturday, October 16, 2021 4:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL EMAIL: Re: System Programmer Titles You guys are doing a lot of disservice to IBM customer engineers everywhere. Thomas Watson named the person who services an IBM piece of equipment a customer engineer in 1942. https://www.practicaladultinsights.com/what-does-a-customer-engineer-do.htm Joe On Sat, Oct 16, 2021 at 6:28 AM Radoslaw Skorupka wrote: > Definitely. When I see soldering, screws, etc. I think about > technician, not engineer. > A person who assemble or fix CPC is technician. > > > > > I mean Polish definitions. > Technician is high school certificate, similar to baccalaureate. > Engineer is technical university graduate, usually got with master of > sciences. > > Our school system (simplified): > First school, 8 years. Start at 7 years old. > Secondary school 4-5 years. Ended with baccalaureate. > University, usually 5 years. Ended with MsC and Engineer for technical > universities. > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > Lennie Dymoke-Bradshaw pisze: > > I think you are possibly misunderstanding what an engineer does. > > > > The root of the word engineer is in the Latin word "ingeniare" > (inventor, designer) and is more associated with things that are > 'ingenious'. So our engineers are more closely associated with design, > rather than screwdrivers and soldering irons. > > > > Lennie Dymoke-Bradshaw > > https://rsclweb.com > > ‘Dance like no one is watching. Encrypt like everyone is.’ > > > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of Skip Robinson > > Sent: 15 October 2021 23:26 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: EXTERNAL EMAIL: Re: System Programmer Titles > > > > A point of clarification. A lot of this revolves around the day to > > day > meaning of 'engineer'. I have never encountered a shop that sends out > systems MTS folks to to open up a hardware box with screwdriver and > soldering iron in order to upgrade or downgrade or repair a Z box. > That practice is SOP in the wienieware world, not in the Z world. > > > > So I repeat: what does a Z systems engineer do that a Z sysprog does > > not > do? > > > > On Fri, Oct 15, 2021 at 2:01 PM CM Poncelet wrote: > > > >> Hi Bruce, > >> > >> I am in the UK. AFAIK CEng is protected by law world-wide > >> (Washington > >> Accord) but not all countries or states recognise it. E.g. Texas > >> admits only the TX PE (Professional Engineer) accreditation and > >> prohibits using the title 'engineer' if not PE licensed, whereas > >> Idaho does recognise CEng if held for 8+ years. It can be a bit > >> complicated. > >> > >> > >> https://www.engc.org.uk/glossary-faqs/frequently-asked-questions/st > >> atu > >> s-of-engineers/ > >> > >> Cheers, Chris > >> > >> > >> > >> On 15/10/2021 05:30, Bruce Hewson wrote: > >>> Hi Chris, > >>> > >>> In which country or countries is your statement correct? > >>> > >>> > >>> On Thu, 14 Oct 2021 21:25:10 +0100, CM Poncelet > >>> > >> wrote: > Anyone can call himself an engineer (e.g. a motor mechanic etc.) > It is illegal for anyone to call himself a *Chartered Engineer* > (CEng) without being qualified and registered as such with an > accredited Engineering institution. HTH. > > Chris Poncelet CEng MBCS CITP > > >>> Regards > >>> Bruce > >>> > >> > > -- > 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
Announcing the new IBM z15 Model T02
Here's an overview from today's announcement: Announcing the new IBM z15 Model T02 -- IBM z15 delivers the cloud our clients want, with the privacy and security they need. Today, April 14th, 2020, IBM Z is announcing the IBM z15 Model T02. The new single frame air cooled IBM z15 Model T02 is designed as the foundation for mission critical workloads in a hybrid multicloud. The IBM z15 Model T02, with a new entry point and lower price, is perfectly aligned for you to have a cloud conversation with all of your clients. Flexibility, responsiveness and cost are fueling the digital transformation and the journey to cloud. Clients need to drive to market faster while addressing cloud security risks and complex migration challenges. Clients need cloud without compromise, they need cloud their way. With IBM Z as part of their hybrid flexible compute, clients can transform their application and data estate with industry-leading levels of data privacy, security and resiliency. They can unleash the power of their developers to build new digital and AI services with predictable and stable cloud pricing. . Cloud native - IBM Z lets clients build new services that are developed anywhere, and deployed anywhere across their cloud with consistent management, orchestration and automation. IBM Z is designed to be an integral part of your client's cloud with containers and Kubernetes on the platform. With Red Hat OpenShift Container Platform clients can "build once, deploy anywhere" across their cloud environment with consistent management, and orchestration using Ansible automation platform. . Encryption everywhere -- IBM Z enables clients to protect their eligible data and ensure privacy by policy wherever their data resides across the cloud. IBM Data Privacy Passports is a data privacy and security enforcement solution with off-platform access revocation. It is designed to protect your client's enterprise and ecosystem's data, regardless of data source, at-rest and in-flight with no performance tradeoffs or application changes. . Cyber resilience -- IBM Z is designed to protect against the impact of cyber attacks by ensuring scalable isolation of workloads, by protecting against insider and external attacks, and ensuring continuous service by mitigating impacts of downtime. Reduce the points of failure in private clouds the impact of planned and unplanned downtime, enabling clients to be back up and running in half the time compared to IBM z14, and catch up on pending workloads, with no increase to IBM software costs. * Flexible compute -- IBM Z is available to businesses of all sizes, from start ups to the largest enterprise. IBM Z provides a flexible approach to deploying compute resources, with the ability to make resources available on demand, to be re-purposed to meet specific requirements, and through on chip acceleration for defined workloads such as cryptography and compression. IBM Storage announcements extend security in compact systems IBM Z is accessible to businesses of all sizes thanks to flexible compute solutions. To keep in sync, the IBM DS8900F and TS7700 families now offer smaller low-cost options to perfectly align with the IBM z15 T02. The entry-level DS8910F model announced last fall, boasts a modest footprint in a rackless configuration that can be mounted in a standard 19-inch rack. And today, TS7700 is announcing virtual tape capabilities delivered as prepackaged racked solutions or rack mounted configurations, with flexible deployments across standard 19-inch racks. The highly reliable IBM TS7700 and DS8900F are the perfect companion to IBM Z offering encryption everywhere, multiple data replication, backup, and protection capabilities such as IBM HyperSwap and Safeguarded Copy technologies. A few key z15 T02 assets available directly for clients to pull down and/or view: Data sheet -> <https://www.ibm.com/downloads/cas/0VZ0KE68> https://www.ibm.com/downloads/cas/0VZ0KE68 Spec sheet -> <https://www.ibm.com/downloads/cas/JD90D9QR> https://www.ibm.com/downloads/cas/JD90D9QR FAQ -> <https://www.ibm.com/downloads/cas/QVMNPQY4> https://www.ibm.com/downloads/cas/QVMNPQY4 3D Virtual Demo -> <https://apps.kaonadn.net/4882011/product.html#14/1401> https://apps.kaonadn.net/4882011/product.html#14/1401 -Mike Smith- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu <mailto: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
Re: Phases of Project in Mainframe
Peter, Parwez identified many of the physical steps necessary. However, from your question I think you were hoping for a more high-level PM-ish kind of answer. >From a very high level the project phases might include the following: Pre-Sales: The Presales Phase should include really understanding your environment and needs. Performing a capacity study and modeling your workload on different capacities is only part of the effort. You need to be educated on the new features and also any newer features from prior generations that might be of interest to you. For example, today your enterprise may have a 10Gb network backbone in place, so you may want to eliminate any 1Gb OSAs (except for the ones used for consoles) and have your new system come in with the 10Gb OSAs. Does you network team have plans to convert your 10Gb backbone to 25Gb in the next three to 5 years? If so, then maybe 25Gb OSAs would be appropriate. Are you running any Linux on z (on IFLs) today? If yes, the perhaps the Container Hosting Foundation feature should be ordered. This is a relatively new feature that, along with support from z/OS 2.4, that allows you to run Linux containers under z/OS with the Linux workload running on zIIP engines, This is an intriguing idea especially for instances where there is fairly tight integration/interaction between the z/OS and Linux portions of the workflow. Just imagine, instead of having to set up a permanent Linux instance running somewhere, you can run it as a step in a batch job! What about your I/O configuration? The z15 can be configured as a single frame CEC if you do not have a really large I/O configuration. Would this be appropriate for your environment? This needs to be identified, discussed and understood in the Presales phase to really determine if it is a viable configuration for your environment. Planning Phase: Next would come the planning phase. this would be a collaborative effort between your team and the IBM or Business Partner team that is working with you on the project. Much of the effort of the project will be in this phase. Many of the things that Parwez identified and many more will be worked on and tracked to ensure that the cutover will be successful. Physical Installation: The Physical Installation is completed by IBM and the machine is cabled to your network, I/O devices, etc. Pre-Production Testing Phase: If it is possible that the current CEC and the new CEC can be up concurrently, this phase may take up to several weeks. During this phase, test and/or sandbox LPARs may be brought up and tested, issues with ISV keys can be identified and corrected, etc. This allows for through testing of the environment before cutting production over to the new CEC. However, if the production cutover needs to occur as close as possible to the physical install, then the Pre-Production testing phase is limited to much shorter time - maybe minutes or an hour or two. Production Cutover is the next phase. This is where the old CEC gets uncabled from the I/O and all effort transfers to getting the new CEC into production. Production Testing Phase The production testing phase immediately follows the production cutover. This phase may last up to several hours if your outage window and client commitments permit it. Milestone: Production testing is followed by a Go/No Go decision Assuming that the decision is Go, you then proceed into the Post Implementation Phase. However, if the decision is a No Go, then you proceed into the Fallback Phase. Fallback Phase. Take all steps necessary to swap the original CEC into production. Then you will need to go back to the Planning or Pre-Production Testing phases. Post-Implementation Phase: Here you would monitor the environment for a few days with a heightened awareness and preform any clean-up from the cutover and pack up the old machine for return. This is obviously a very high level list and a lot of detail needs to be included. The vendor team (either IBM or your IBM Business Partner) should assist you with developing and implementing the plans. The complexity and size of the planning effort varies for customer and each installation within that customers environment. I hope this helps. Regards, Mike Smith -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Parwez Hamid Sent: Monday, February 3, 2020 12:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Phases of Project in Mainframe This will differ for each customer and there will be a number of dependencies. Key phases should cover (each topic will have its on subtasks): 1) Physical Planning (physical planning/power/space/channel cabling/network connectivity/HMCs etc etc) 2) Operating System levels etc 3) Capacity Planning. LPAR planning/configuration 4) ISV Software/products levels 5) Applications 6) DR/Backup 7) Operations procedures I am s
Re: Remote access to Z14 ZR1 Support Element via HMC question
There are some new fields in the OSA-ICC definitions. I have had success by importing the old definitions via a thumb drive, then editing them on the HMC. That will populate the new fields when you save the definition. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Laurence Chiu Sent: Wednesday, March 27, 2019 1:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Remote access to Z14 ZR1 Support Element via HMC question I'm wondering that too. The Redbook https://www.redbooks.ibm.com/redbooks/pdfs/sg248460.pdf Page 149 says when installing a new Z14 you must configure OSA-ICC from scratch and I wonder if they thought that could just copy the configuration from the zBC12 I hate to ask the techs these questions when I'm only the PM but it can't hurt I guess? On Wed, Mar 27, 2019, 8:50 PM Peter wrote: > Could be client IP hasn't been defined in the session table.try adding it > and check > > On Wed, 27 Mar, 2019, 11:47 AM Laurence Chiu, wrote: > > > Well I don't know what the techs did but they managed to access the z14 > > HMC, copy across LPAR, IOCDS etc. and we've successfully IPL'ed a couple > of > > LPARs from the same DS8870 that our zBC12 uses. That's progress, > > > > But now we are finding that we cannot access the OSA-ICC for remote > access. > > The user gets the logon screen but cannot progress. I wonder if it's > > because the LU name or client IP hasn't been defined in the session > table? > > > > On Mon, Mar 25, 2019 at 3:54 PM Mike Smith wrote: > > > > > Laurence, > > > > > > The Top Guns are different for each region. The best way to get the > > > proper one involved would be to contact the SSR directly or open a HW > > > incident. > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > > Behalf Of Laurence Chiu > > > Sent: Sunday, March 24, 2019 5:58 PM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Remote access to Z14 ZR1 Support Element via HMC question > > > > > > 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? > > > > > > l 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Remote access to Z14 ZR1 Support Element via HMC question
Laurence, The Top Guns are different for each region. The best way to get the proper one involved would be to contact the SSR directly or open a HW incident. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Laurence Chiu Sent: Sunday, March 24, 2019 5:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Remote access to Z14 ZR1 Support Element via HMC question 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 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 > 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) w
Re: Remote access to Z14 ZR1 Support Element via HMC question
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 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 on behalf > of Laurence Chiu > 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 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 on > > behalf of Laurence Chiu > > 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
Re: Remote access to Z14 ZR1 Support Element via HMC question
What is the feature Code of the HMC on the zBC12? That will determine the maximum driver level that can be applied, but I doubt that it's the same driver level as the z14. In prior conversations with our Top Gun I was led to believe that an HMC associated with a zBC12 will not see the HMC on a z14. Of course, I could be wrong, but the only way it might work would be if you got an extra HMC FC0082 or FC0083 with the z14 and replaced the old zBC12 HMC. The earlier notes mentioned that you resolved the firewall issues so you must have found the documentation relating to the additional ports that need to be opened for a z14. Did you also see the information about the new IP addresses that need to be accessed through your firewall so the z14 can contact the new "Enhanced" Support Center? Regards, Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Laurence Chiu Sent: Thursday, March 21, 2019 11:46 AM 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 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 on behalf > of Laurence Chiu > 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=isg23e9d1b6de8c163f985258195006801cc > 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 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
Re: Identifying and eliminating uncataloged datasets
Be very careful running DFDSS to delete uncataloged datasets. Make certain you understand the complete catalog structure. I would not be surprised to see that "uncataloged" SYS1.* datasets are actually active and in use on other running systems. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Doug Sent: Monday, February 25, 2019 6:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Identifying and eliminating uncataloged datasets Tony, Please consider that SYS?.** datasets might be on volumes that represent the previous running system volumes. Do the volumes look like previous 'sysres' volumes? My 2 cents, take some time to investigate the date and contents, might be you don't want to trash them yet. On the other hand, if you are sure you have the ability to recover your running system and do know what your fall back system is them, blast away. Just my 2 cents.. Doug On 2/25/2019 20:54, Wayne Bickerdike wrote: > ADRDSSU if you have it. > > Dump and delete the uncataloged datasets. > > Later you can RESTORE with a new HLQ if desired. > > //STEP1EXEC PGM=ADRDSSU > //SYSPRINT DDSYSOUT=A > //DASD1DDVOL=SER=MYVOL1,UNIT=SYSDA,DISP=OLD > //DASD2DDVOL=SER=MYVOL2,UNIT=SYSDA,DISP=OLD > //TAPE DDUNIT=3480,VOL=SER=TAPE04,LABEL=(1,SL), > // DISP=(NEW,CATLG),DSN=USER3.BACKUP > //SYSINDD* >DUMP DATASET(INCLUDE(**) - > BY((DSORG NE VSAM) - >(CATLG EQ NO))) - > LOGINDDNAME(DASD1,DASD2) - > OUTDDNAME(TAPE) - > DELETE PURGE > /* > > > > On Tue, Feb 26, 2019 at 11:28 AM Tony Thigpen wrote: > >> I have inherited a system where nobody bothered to clean-up after >> themselves. If I do a DITTO VTOC of all the volumes, I can sometimes >> find 5 or 6 copies of the same dataset, some of which are SYSx.*. >> >> I would like to first rename all the uncataloged versions so I can >> eventually delete them. >> >> Does anybody know of a free tool that would help with this process? >> >> -- >> Tony Thigpen >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- 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
Re: z/OS 2.3 Memory Requirements on z14
Not quite. The minimum amount of memory on a z14 ZR1 is 64GB (256GB on the larger z14). At first, 64GB sounds like "plenty." But if you are supporting a number of LPARs with small memory allocations, you can use of the 64GB pretty quickly. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, February 25, 2019 11:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 2.3 Memory Requirements on z14 Maybe I am incorrect, but I thought when you ordered a z14 it could come with triple the amount of memory for the same cost of memory you were currently paying. For example, if you were using on a NON z14 8G, then when you order a z14 it could done with 24G but at the same price as the 8G memory. Or was that one of IBM's wild marketing promises. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Mike Smith > Sent: Monday, February 25, 2019 8:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: z/OS 2.3 Memory Requirements on z14 > > Can anyone share their experiences running z/OS 2.3 on a z14 or z14 ZR1 in an > LPAR with less than the required 8GB of memory? Other than having to respond > to the warning message during IPL, have any negative effects been > experienced? > > Background: > Excerpt From: > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3. > e0zm100/BCP_zNext_Memory_Reqs_V2R3.htm > > Ensure that enough real memory is installed > > Description > > For z/OS V2R3 with the IBM z14™ (z14) server, a minimum of 8 GB of real > memory is required to IPL. When running as a z/VM guest or on an IBM Z® > Personal Development Tool (zPDT), a minimum of 2 GB is required for z/OS > V2R3. > > If you attempt to IPL z/OS V2R3 on a z14 with less than the minimum amount of > real memory, z/OS issues the following warning message (a WTOR) during IPL: > IAR057D LESS THAN 8 GB OF REAL STORAGE IMPACTS SYSTEM AVAILABILITY - ADD > STORAGE OR REPLY C TO CONTINUE > > Continuing with less than the minimum amount of real memory might impact the > availability of your system. If you attempt to IPL z/OS V2R3 on an earlier > IBM server, no warning message is issued. > > -- > 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
z/OS 2.3 Memory Requirements on z14
Can anyone share their experiences running z/OS 2.3 on a z14 or z14 ZR1 in an LPAR with less than the required 8GB of memory? Other than having to respond to the warning message during IPL, have any negative effects been experienced? Background: Excerpt From: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0zm100/BCP_zNext_Memory_Reqs_V2R3.htm Ensure that enough real memory is installed Description For z/OS V2R3 with the IBM z14™ (z14) server, a minimum of 8 GB of real memory is required to IPL. When running as a z/VM guest or on an IBM Z® Personal Development Tool (zPDT), a minimum of 2 GB is required for z/OS V2R3. If you attempt to IPL z/OS V2R3 on a z14 with less than the minimum amount of real memory, z/OS issues the following warning message (a WTOR) during IPL: IAR057D LESS THAN 8 GB OF REAL STORAGE IMPACTS SYSTEM AVAILABILITY - ADD STORAGE OR REPLY C TO CONTINUE Continuing with less than the minimum amount of real memory might impact the availability of your system. If you attempt to IPL z/OS V2R3 on an earlier IBM server, no warning message is issued. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
I vote for Bruce's method also. This will allow multiple versions (a maintenance version of current and the next Version release) to be mounted at the same time. Allows two people or parallel work on both systems. I even went so far as to write a REXX routine which would create the mount point if it did not exist, read the BPXPRMxx member of parmlib for all the File Systems, and mount and/or create mount point/mount the files systems for the select SYSRES set. All the DDEFs for the SYSRES set used the same path prefix '/RESVOL1' . This is easy to zoneedit after a clone also. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
