Browse Prior Art Database

Method to Allow Diagnostics Developed by a Third Party to Be Integrated Into Released Diagnostics

IP.com Disclosure Number: IPCOM000039987D
Original Publication Date: 1987-Sep-01
Included in the Prior Art Database: 2005-Feb-01
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Browning, LM: AUTHOR [+3]

Abstract

A method is described for use on the RT PC model of personal computers which permits Third Party Diagnostics to be executed from the IBM RT PC Diagnostic Package, which expedites the development of new devices. Third Party Diagnostics (TPD) can now be executed in privileged mode as an application of the RT PC Diagnostic Control Program (DCP). The Third Party Developer is given a virtual machine that operates in a mode usually associated with an operating system. In addition, the vendor is given the services of both the DCP and the Virtual Resource Manager (VRM). The DCP provides runtime support, terminal I/O, and device management. TPD can be executed before or after IBM diagnostics without restarting the machine.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 2

Method to Allow Diagnostics Developed by a Third Party to Be Integrated Into Released Diagnostics

A method is described for use on the RT PC model of personal computers which permits Third Party Diagnostics to be executed from the IBM RT PC Diagnostic Package, which expedites the development of new devices. Third Party Diagnostics (TPD) can now be executed in privileged mode as an application of the RT PC Diagnostic Control Program (DCP). The Third Party Developer is given a virtual machine that operates in a mode usually associated with an operating system.

In addition, the vendor is given the services of both the DCP and the Virtual Resource Manager (VRM). The DCP provides runtime support, terminal I/O, and device management. TPD can be executed before or after IBM diagnostics without restarting the machine. Moreover, this integration of code has been implemented in such a way as to reduce the impact of the execution of the code upon that of IBM's. The system garbage collects the resources held in common between the applications. Devices are disconnected and deleted. The segments used to hold the application code and device driver code is reclaimed. The heap is reset to reflect only the allocations of the DCP. All AIX files are closed. Two requirements are placed on the third party: - The executable code must be placed in a directory labeled

'/VENDOR' of an AIX file system.

- The compiler used must be either the RT PC C compiler, or the

PL.8 compiler. Every file found in the predefined directory will be executed. First, it is loaded into a segment set aside specifically for this purpose and then it is dynamically bound to the DCP. This process links a discrete set of Run Time Routines contained in the DCP and any references to these routines in the application. There are approximately 52 of these routines available.

Modules written in C have to be preprocessed by the VRM conversion utility that translates a C module into a PL.8 module. The following services are represented. - Allocation of stack space.

- Terminal I/O via PL.8 display and reply statements.

- Character manipulation.

- Allocation and freeing of controlled and base variables. The DCP can also be referenced via a supervisory call. There are 42 services that can be requested in this manner. Most notable among these are: - Terminal and File I/O implemente...