> Setting up a separate PC (unless your box doesn't support the
> ICC consoles) is really not necessary.
Experience suggests otherwise.
The separate PCs for the primary consoles has come about because of our
experience with network failures. They are connected directly to the
same switch as the OSA-C. So, you never loose all the consoles over an
extended timeframe. (We don't have anyone on-site so they can fail and
we might not know it for weeks.)
Laptops are used because they are not on the same UPS as the CPU's (we
have several z CPUs). The battery gives us a long non-power run-time
since the lid is closed and the screen is off. (We only access them via
RDP.)
Tony Thigpen
Brian Westerman wrote on 09/30/2016 04:03 AM:
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
________________________________
Warning: All e-mail sent to this address will be received by the corporate
e-mail system, and is subject to archival and review by someone other than the
recipient. This e-mail may contain proprietary information and is intended only
for the use of the intended recipient(s). If the reader of this message is not
the intended recipient(s), you are notified that you have received this message
in error and that any review, dissemination, distribution or copying of this
message is strictly prohibited. If you have received this message in error,
please notify the sender immediately.
________________________________
----------------------------------------------------------------------
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
