Browse Prior Art Database

Internal Diagnostic Communication

IP.com Disclosure Number: IPCOM000118293D
Original Publication Date: 1996-Dec-01
Included in the Prior Art Database: 2005-Apr-01

Publishing Venue

IBM

Related People

Pironio, C: AUTHOR

Abstract

Diagnostics running in the Extended Diagnostic Environment (EDE) of the reference diskette are first called by the Diagnostic Control Program (DCP) for a presence test. During this time, some diagnostics initialize the hardware. Hardware, such as Small Computer System Interface (SCSI) and its attached devices, can be tested by several isolated diagnostics.

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

Internal Diagnostic Communication

      Diagnostics running in the Extended Diagnostic Environment
(EDE) of the reference diskette are first called by the Diagnostic
Control Program (DCP) for a presence test.  During this time, some
diagnostics initialize the hardware.  Hardware, such as Small
Computer System Interface (SCSI) and its attached devices, can be
tested by several isolated diagnostics.

      The problem is that these diagnostics have no way of
determining if the hardware is already initialized.  These
diagnostics may have redundant code used to interface the hardware,
thus taking Random Access Memory (RAM) needed to load other
diagnostics.  The Inter-diagnostic Communication software solves the
problem of diagnostic  isolation within the EDE of the reference
diskette.  It allows diagnostics programs to communicate with each
other by transferring data  a d/or control.

      Inter-diagnostic communication - The solution is to provide a
simple interface where one diagnostic can send a message to another
diagnostic and viceversa.  DCP provides a macro (an ASM procedure) to
perform this task.

      The internal protocol between diagnostics is defined by the
developers of such diagnostics.

An example of a diagnostic defined inter-diagnostic protocol could be
the following:
  o  code_01 - Send status    port 1
  o  code_02 - Send status    port 2
  o  code_03 - Send status    port 3
  o  code_04 - Reset port 1
  o  code_05 - Reset port 2
  o  .....

The protocol must be handled by all diagnostics using this interface.

      Diagnostics that run in the EDS environment can have the
following file extensions DGS, DGC or DGR (for more information,
please refer to the Diagnostic Control Program Workbook).

      Diagnostics with extension type DGC (code) or DGR (driver) can
use the inter-diagnostic communication process as long as they are
RAM resident at the time the communication takes place.

      Each diagnostic has a unique identification number assigned by
architecture; this number is called Process ID (PID) number.

A diagnostic program can:
  1.  Send an inter-diagnostic message to another PID
       (diagnostic or driver module) and
      o  Wait for a response from the other PID.
      o  Relinquish temporary control to the other PID.
      o  Transfer complete control to the other PID.
  2.  Receive an inter-diagnostic message from another PID.

      The inter-diagnostic message can carry data or a pointer to a
data area.

      The SEND_MSG_TO_PID macro is used to communicate with
diagnostics.  The macro requires the destination PID, the sender's
PID, the message type, the message code and if a buffer is required
for this protocol, then the segment and offset to the buffer.

      The macro saves the parameter data in the Mail box area of the
Diagnostic Control Program that was defined for inter-diagnostic
communication.

The foll...