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

External Program Loading of Secondary Processors

IP.com Disclosure Number: IPCOM000047149D
Original Publication Date: 1983-Oct-01
Included in the Prior Art Database: 2005-Feb-07
Document File: 3 page(s) / 31K

Publishing Venue

IBM

Related People

Heath, CA: AUTHOR

Abstract

In certain contemporary systems, "intelligent" I/O controllers containing integral microprocessors are used as secondary data processing systems to offload certain processing functions from host (mainframe) processors. Such secondary processors may be adapted to receive initial loading of command sets representing secondary programs from an associated host processor, and may store and later execute such programs in response to initiating commands from the host processor. The secondary processor may save up execution status information for one or more such programs and transfer aggregate status to the host via single interruption. In one presently known system, the vehicle for initiating the loading of such secondary programs is a device control block vector (DCB) specifically designated as a loading operator or "load DCB".

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

External Program Loading of Secondary Processors

In certain contemporary systems, "intelligent" I/O controllers containing integral microprocessors are used as secondary data processing systems to offload certain processing functions from host (mainframe) processors. Such secondary processors may be adapted to receive initial loading of command sets representing secondary programs from an associated host processor, and may store and later execute such programs in response to initiating commands from the host processor. The secondary processor may save up execution status information for one or more such programs and transfer aggregate status to the host via single interruption. In one presently known system, the vehicle for initiating the loading of such secondary programs is a device control block vector (DCB) specifically designated as a loading operator or "load DCB". The information in a load DCB can be used by the secondary processor to instigate a direct memory access to the host system memory and to remove therefrom a secondary program of varied length. Such load DCB operations may be architected to define reentry to a previously loaded secondary program from a starting command position defined by information in the load DCB. In such "implied loading" applications, a bit or field in the load DCB indicates the reentry position. Obviously, for explicit loading, the host system usually must acquire such secondary programs from its attached peripherals, store the same in its (main) memory and then issue the load DCB operator to the secondary controller/processor. It is recognized presently that if the peripheral which is the source of the secondary program is already attached to the secondary controller/processor, it would be more efficient to directly load that program, and thereby avoid the storage of the program in host main memory and the associated scheduling and I/O procedures. For this purpose, it is proposed presently that the field in the load DCB which distinguishes between implicit and explicit loading of a secondary program may be used (by additional coding) to distinguish an "external loading" procedure.

In response to a load DCB specifying external loading the secondary microprocessor would become receptive to receiving both a secondary program, and a control signal for initiating offline execution of that program, from one of its p...