We have maintained physical NIP consoles literally forever: as long as we've had IBM mainframes. Until maybe the mid-90s, there was no alternative. Now there are several, ranging from OSA connected PC emulation to the HMC itself, local or remote. I've been questioning our configuration for a while. Some issues:
1. There must be a NIP console available to an 'operations person', whether designated Operator or button-pushing sysprog. While most of our IPLs are handled entirely by automation at least as far as ' IEE389I MVS COMMAND PROCESSING AVAILABLE', there are conditions that stop IPL before that with a WTOR. The most notorious is duplicate volser. The system will wait forever even though you may not care at all which volume stays online. 2. The HMC is not the friendliest user interface to z/OS. Nuff said. 3. If you have a lot of systems to manage, the HMC becomes more and more awkward. We have 14 z/OS images on a daily basis plus half a dozen more during DR exercises. Any of them might need NIP interaction at some point. HMC gets even more awkward. Years ago we went with Visara VCC, a mid-range application that connects to each CEC via OSA-C. An operator can reach any system in the enterprise by selecting it from a menu. More than one person can access the same system at one time, although the effect of multiple--maybe conflicting--commands can be troublesome. 99.9% of the time VCC is a fabulous tool, but we have had instances of VCC misbehavior. Once a system is 'up', there are other operator interfaces available. At NIP time however, which I define as anything before IEE389I, a NIP console as designated in the IODF may be required. If the failing VCC 'device' is a NIP, we can be SOL. If the VCC failure is detected by NIP, the operator interface will automatically switch to HMC SYSCONS. But we've had cases where NIP thinks the VCC console is available. Only it ain't. I know of no other way out than to force the VCC chpid offline at the HMC and reIPL. With no path to a console, NIP will push the operator interface to SYSCONS. So, if we might require the HMC in a pinch, maybe we should step back and define no NIP console at all. Let VCC handle MVS command processing but always use the HMC at IPL time. This assumes of course that the HMC is accessible remotely via VPN (or whatever). If that is prohibited by management, then never mind. But if it's permissible, then the question is one of operational usability, best practice, and worst-case CYA. End of treatise. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Brian Westerman Sent: Friday, September 30, 2016 1:04 AM To: [email protected] Subject: (External):Re: EXTERNAL: Re: remote system support (i.e. the data center is 2 states away from you). I'm actually kind of surprised at the number of sites that don't code the OSA-ICC consoles as NIP available. They were designed to function in that manner, and you can then always have remote access (assuming you have a VPN). If you don't have a VPN set up for your mainframe, you are just asking for trouble. If you do have one, then not using it to support the box seems very silly indeed. Setting up a separate PC (unless your box doesn't support the ICC consoles) is really not necessary. Brian On Wed, 28 Sep 2016 16:17:25 -0400, Tony Thigpen <[email protected]> wrote: >Our remote systems support staff have multiple remote access to the >consoles: >1) The initial IPL console is on a laptop in the computer room with >Windows 7 PRO. If needed, this box can be remotely accessed using RDP >over a VPN. >2) A backup console is always running on a second laptop with the same >RDP over VPN access. >3) Each sysprog has their own dedicated console which is accessed via >the OSA-C. I connect and keep my personal console running all the time >but minimized. >4) We have one person in town that lives only 5 minutes from the >data-center. We can always call them. >5) There is another company in the same building that manages WinTel >servers. They have access to our data-center and can be called 24/7. > >Tony Thigpen > >Jerry Whitteridge wrote on 09/28/2016 01:34 PM: >> This indicates a weakness in your console deployment - my staff have >> remote access to all the consoles they need (including the Master) >> >> Jerry Whitteridge >> Manager Mainframe Systems & Storage >> Albertsons - Safeway Inc. >> 925 738 9443 >> Corporate Tieline - 89443 >> >> If you feel in control >> you just aren't going fast enough. >> >> >> >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] >> On Behalf Of Edward Gould >> Sent: Wednesday, September 28, 2016 9:10 AM >> To: [email protected] >> Subject: EXTERNAL: Re: remote system support (i.e. the data center is 2 >> states away from you). >> >>> On Sep 28, 2016, at 12:28 AM, Brian Westerman >>> <[email protected]> wrote: >>> >>> Hi John, >>> >>> Our company (Syzygy Incorporated) fully supports more than 70 sites >>> remotely, all over the world. On top of that we provide partial support >>> for another 60 to 70 sites. Some are large (300+MSU) and some are quite >>> small (8 to 10 MSU), but they all need our expertise and not being >>> "on-site" has never been an issue. We also have a suite of system >>> automation products that we maintain at several hundred sites. >>> >>> Even 10 to 12 years ago, it was very unusual to be "at" a site or if >>> you were physically there, to be anywhere near the actual computer >>> room. Once a site realizes that the systems programmer doesn't need >>> to be in that room, it's only a small jump for them to understand >>> that you get just as much support from the next floor, or the next >>> building, or the next city, etc. I can still remember some >>> knock-down drag out fights between the systems programmers and the >>> operations group on whether or not the systems programmers should >>> ever be allowed into the computer room. We (systems programmers) >>> always won that argument, but now I wonder why I fought it for so >>> long. :) >> ——————————SNIP——————————————— >> >> I will disagree with you on this one. Our data center is on 2 floors and >> running upstairs is still needed as consoles (except the master) is still >> needed to this day. Just last week all consoles (except the master) were >> locked out (TSO was dead as were other possibilities). We were able to get >> the system back (and working in good order) by a combination of operator >> commands. >> >> Ed ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
