{
{     The purpose of this request is to cause a PP to begin executing a
{ program for the purpose of diagnosing mainframe or peripheral failures.
{ A communication-buffer is also provided to permit the requesting program
{ to interchange data or control information with the PP program.
{     If a system interrupt should occur during the execution of the PP
{ program, the content of the PP's memory and location and contents of the
{ the communication buffer is not recovered nor is this request automatically
{ re-issued.  The recovery and the continuation of PP execution is the
{ responsibility of the program.
{     The execution of the PP program may be terminated by using the
{ cmp$idle_pp request.  If such a request is not issued, then the PP execution
{ is terminated when the task which issues this request is terminated.  In
{ either case, any channel interlock(s) set by this PP are cleared.
{     If a multiple-PP solution is required, this interface may be used
{ to load and execute the same or a different program in each PP.
{
{         CMP$EXECUTE_PP_PROGRAM (PROGRAM_DESCRIPTION, STATUS)
{
{ PROGRAM_DESCRIPTION: (input,output) This parameter specifies the identity of
{ the
{        PP(s) to be initialized, the identity of the program to be loaded in
{        the PP(s) and the peripheral element(s), if any, to be accessed.
{        A PP-interface-table is created for each PP described by this
{        parameter.
{        Up to two PPs may be initialized by this request.  This parameter is
{        specified as an array of 1 or 2 records, each consisting of the
{        following fields:
{
{        The pp_identification field (input) specifies which PP is to be
{        executed.  The PP must previously have been reserved to the requesting
{        job using the cmp$reserve_element request.
{
{        The iou_program_name field (input) specifies the name of the program
{        whose contents is described in the pp_program_field.  This name is
{        provided for presentation in system displays.
{
{        The pp_program field (input) specifies the image of the PP program to
{        be executed in the PP.  A PP program is essentially an array of 16-bit
{        PP-memory  bytes, four per CM word.  The first 16-bit byte (address 0
{        in PP memory) contains the address minus one of the start of the PP
{        program.  The hardware 'jumps' to the contents plus one of PP address
{        0
{        to complete the deadstart process.  Addresses 72(8) and 73(8) of the
{        PP program are reserved by convention for the real-memory address
{        of the PP's PP-interface-table; this interface initializes these two
{        locations in the PP's memory prior to giving control to the PP
{        program.
{        Note that if the PP program is stored in a NOS/VE object library, a
{        pointer to the PP object module may be obtained by using the
{        pmp$open_object_library and pmp$find_module_in_library requests.
{
{        The master_pp field (input) specifies whether or not the PP is to be
{        the "boss" in a multiple-pp implementation of a peripheral device
{        PP program.  If the PP is not the master, i.e. a value of FALSE is
{        specified, bit 31 of the PP's communication-buffer word 1 is set to 1.
{
{        The element_access field (input) specifies the hardware address to
{        each
{        peripheral element to be accessed.  A NIL pointer may be used to
{        specify that no peripheral elements are to be accessed, in this
{        case only a PP-interface-table is created for the PP.
{        If a peripheral element is to be accessed, the complete path to the
{        element, i.e. IOU, channel, channel_address and/or unit_address must
{        be
{        specified.  If a storage device is in the active configuration, only
{        one
{        unit-interface-table will be created for the storage device even
{        though
{        there may be multiple paths to it.  If a storage device is not in the
{        active configuration, this request cannot determine whether two
{        hardware
{        addresses lead to the same storage device or to two different ones;
{        therefore, a unit-interface-table will be built for each hardware
{        address
{        supplied.  A unit-descriptor will be built in the pp-interface-table
{        for
{        each element identified by this field.  All elements identified must
{        have
{        either been previously reserved to the job using the
{        cmp$reserve_element
{        request or have been the object of an msp$request_maintenance_access
{        request.
{
{        The communication_buffer_length (input) field specifies the length of
{        real-memory assigned to the PP-communication-buffer assigned to the
{        PP.
{        The communication buffer is guaranteed to be contiguous in real-memory
{        and therefore is tied to the page-size of the mainframe.
{
{        The communication_buffer (input, output) specifies a pointer variable
{        which is initialized as a result of this request.  The pointer
{        variable
{        is initialized by this request to point to the communication buffer
{        assigned to the PP.  The "limit" value in the ^seq(*) is initialized
{        to the length of the communication buffer allocated.  The
{        communication
{        buffer is assigned to a unique segment which has the property that
{        real-memory assigned to the segment is never paged-out nor is it
{        released when the job is swapped.  This permits the PP to reference
{        the communication buffer at all times.  An attempt to page-fault
{        beyond
{        the length of the assigned communication buffer will cause a segment-
{        access-condition.
{
{        Each PP is provided its own communication-buffer.
{        By convention, the first word of each communication-buffer is
{        initialized as follows:
{                                       3                               6
{        0______________________________1_______________________________3
{        |000000000000000000000000000000S             RMA of PPIT       |
{        ----------------------------------------------------------------
{
{        Where:
{              S=1 if the PP was designated as a slave PP.
{              S=0 if the PP was designated as the master PP.
{
{              RMA of communication buffer is the real memory address of
{                the partner's PP-interface-table.
{
{
{ STATUS: (output) This parameter specifies the request status.
{
{         CONDITIONS:
{                     cme$lcm_element_not_found,
{                     cme$lcm_empty_pa_set,
{                     cme$lcm_missing_pa_set_member,
{                     cme$lcm_not_available,
{                     cme$lcm_ring_validation_error,
{                     cme$privileged_job_required,
{                     cme$too_many_pp_program_desc,
{                     cme$buffer_length_too_large,
{                     cme$page_size_too_small.
{
{         IDENTIFIER : 'CM'
{
