Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Intra-Network Communications using Hardware-Software Internetworking

IP.com Disclosure Number: IPCOM000104821D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 6 page(s) / 125K

Publishing Venue

IBM

Related People

Enichen, MC: AUTHOR [+2]

Abstract

Disclosed is a method of combining an existing service-processor (hardware) network in a computer system, and an operating system (software) network for establishing alternate paths, and for enhancing the capabilities of each of the two networks. The mechanism enables the routing of commands, messages, responses, and alerts between MVS/ESA* images in a network. This solution treats MVS images and processor controller elements (PCEs, a.k.a. service processors) as "peer" nodes in a network for routing purposes, even though the MVS-to-service processor connection is not a network connection. This solution makes MVS-to-MVS communication possible when MVS is running with all interrupts disabled or when normal operating system network connectivity has been lost. (Refer to Figure 1.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Intra-Network Communications using Hardware-Software Internetworking

      Disclosed is a method of combining an existing
service-processor (hardware) network in a computer system, and an
operating system (software) network for establishing alternate paths,
and for enhancing the capabilities of each of the two networks.  The
mechanism enables the routing of commands, messages, responses, and
alerts between MVS/ESA* images in a network.  This solution treats
MVS images and processor controller elements (PCEs, a.k.a.  service
processors) as "peer" nodes in a network for routing purposes, even
though the MVS-to-service processor connection is not a network
connection.  This solution makes MVS-to-MVS communication possible
when MVS is running with all interrupts disabled or when normal
operating system network connectivity has been lost.  (Refer to
Figure 1.)  If a situation arises where MVS1 must communicate with
the operator during recovery and connectivity to MVS console(s)
attached to CEC1 (Central Electronic Complex 1) has been lost, MVS
constructs an operator message and passes it to SVP1 (service
processor 1) via the service-call logical processor (SCLP) interface.
(This communication path is usable while MVS is running disabled,
while the MVS1-to-MVS2 path via operating system network is not.)
SVP1 routes the message to SVP2, which then passes the message to
MVS2 via the service processor network.  MVS2 can then display the
message on the alternate console connected to CEC2.  Should the
operator respond by issuing a MVS command, the command will be routed
to MVS1 by the reverse path: MVS2 -> SVP2 -> SVP1 -> MVS1.

      This solution provides the full connectivity between the
systems in the network (hardware and software connections) to MVS
Console Services for routing MVS messages.  Several MVS images may be
traversed in order to reach an operational console, while from the
perspective of the issuing system the console activity is
"synchronous".  Refer to Figure 2.  Using the combination of
operating system and service processor networks can also allow an MVS
image to route communication to an MVS image running in a processor
which itself is not a part of the service processor network.  In
Figure 2, the communication flow could take the path
MVS1->SVP1->SVP3->MVS3->MVS2.

      This solution allows the hardwar...