I need a zIIP (or zAAP) first

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]]
> On Behalf Of Cheryl Watson
> Sent: Wednesday, September 28, 2016 12:52 PM
> To: [email protected]
> Subject: Re: remote system support (i.e. the data center is 2 states away from
> you).
> 
> I can highly recommend z/OSMF.  Steve - have you tried the install on z/OS
> 2.2?  It's considerably easier there.
> 
> Cheryl
> 
> 
> Cheryl Watson
> Watson & Walker, Inc.
> 100 Central Ave, Suite 1013
> Sarasota, FL 34236
> P-941-924-6565, F-941-924-4892
> www.watsonwalker.com
> 
> 
> 
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]]
> On Behalf Of Steve
> Sent: Wednesday, September 28, 2016 3:03 PM
> To: [email protected]
> Subject: Re: remote system support (i.e. the data center is 2 states away from
> you).
> 
> 
> You might look at z/OSMF but don't be fooled, it will take you a while to get
> up
> 
> Steve Beaver
> [email protected]
> 
> 
> --------------------------------------------------------------------------------
> 
> This electronic mail (including any attachments) may contain information that
> is privileged, confidential, and/or otherwise protected from disclosure to
> anyone other than its intended recipient(s). Any dissemination or use of this
> electronic email or its contents (including any attachments) by persons other
> than the intended recipient(s) is strictly prohibited. If you have received 
> this
> message in error, please notify us immediately by reply email so that we may
> correct our internal records. Please then delete the original message
> (including any attachments) in its entirety. Thank you
> 
> 
> -----Original Message-----
> From: "Jesse 1 Robinson" <[email protected]>
> Sent: Wednesday, September 28, 2016 2:24pm
> To: [email protected]
> 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.
> 
> .
> .
> 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 Jerry Whitteridge
> Sent: Wednesday, September 28, 2016 10:49 AM
> To: [email protected]
> 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:[email protected]]
> On Behalf Of Jerry Whitteridge
> Sent: Wednesday, September 28, 2016 10:35 AM
> To: [email protected]
> 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:[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
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> [email protected] with the message: INFO IBM-MAIN
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to