Reposting to add comments on HMC. See below. -----Original Message----- From: Jesse 1 Robinson Sent: Wednesday, September 28, 2016 11:25 AM To: 'IBM Mainframe Discussion List' <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: remote system support (i.e. the data center is 2 states away from you).
Amen to what Jerry said. I just want to substitute the word '(re)design'. Our IT operation was originally 'designed' back in the day when everything was connected via copper cable. You pretty much had to enter the Operations cave in order to get to 'the heart' of anything. Over the years connections became more and more virtual. However, replacing old technology was easy compared with replacing old attitudes. Long after remote HMC access appeared, we were stymied by one individual in the Security area blocked us. That person never converted; he just moved on. So now there is a hierarchy of remote access and control. 1. SDSF (or comparable product). Allows the user to issue commands and see responses. 2. SMCS. Can be used when TSO is hung up. Can issue commands and see responses sent to the console. 3. VCC. Off mainframe product that presents a console image to the user. Requires no mainframe function other than the OS. Active during NIP. 4. HMC 'native' 3270. Works like a traditional console. Requires z/OS 2.1. 5. HMC Operating System Messages. Non-3270 look and feel. Requires nothing more than connectivity to HMC. Each of these has advantages and disadvantages. -- SDSF allows the user to examine operlog for responses and past activity but depends on healthy TSO, which can be blocked by 100% spool full. Very powerful. Shows messages that are not displayed on a console. -- SMCS gets only messages directed to 'console' but depends only on a healthy VTAM; unaffected by a spool full condition. Still depends on a healthy SAF. -- VCC is a separate product that requires its own hardware and TLC and $$. Allows convenient switching among all connected systems. -- HMC 3270 is nice but at present allows only one user at a time per system. Not suitable for round-the-clock use. -- HMC OSM allows multiple users but is clumsy (says the self-confessed 3270-phite). Does allow some back scrolling but even that is clumsy. Probably the most available of all interfaces, but I don't know of anyone who relies on it solely. +++++++++++++++ Update: until recently OpSysMsgs depended on the user's workstation Java. That was a real problem because a new release of Java often broke OSM, so you had to keep your old version around just for that purpose. I got issued a new laptop in January and could never find a release of Java that would do OSM. At SHARE in San Antonio I learned that an upcoming HMC microcode upgrade would no longer require Java at all. Had IBM install Driver 13 as soon as possible, and sure enough, OSM works fine now. Driver 13 works on z196 at z/OS R13. That driver is required for z/13 anyway, so you might as well get ahead of the curve. +++++++++++++++ . . 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 robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Wednesday, September 28, 2016 10:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: EXTERNAL: Re: remote system support (i.e. the data center is 2 states away from you). Let me expand on that previous comment. If your Datacenter was/is designed for attended operations then console access is often restricted to physical access and so remote support becomes an issue. The conversion to unattended/lights out operations requires a rethink about console design, deployment and access from the traditional models. Both my Datacenters are designed for remote support (either can be run from either Datacenter OR by remote access). This was a part of the DR considerations as well as staffing choices. It did mean redesigning the console support but now we have access to any console from any authorized remote location without a physical presense. 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Wednesday, September 28, 2016 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: EXTERNAL: Re: remote system support (i.e. the data center is 2 states away from you). 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edward Gould Sent: Wednesday, September 28, 2016 9:10 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 <brian_wester...@syzygyinc.com> > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
