{
{    The purpose of this request is to receive data from a peer application
{  over an established CDNA Session connection.  This request is also used to
{  obtain notification of peer operations other than sending data.
{
{    Data transmitted over a connection is structured into messages.  Message
{  boundaries are specified by the sender and communicated to the receiver.
{
{    There are two operations involved in the transfer of data between peer
{  applications.  The sending application performs a send data operation to
{  transfer data into the connection.  The receiving application performs a
{  receive data operation to transfer data out of the connection.
{
{    The network holds a certain amount of data within a connection to smooth
{  out the interaction between a sender and a receiver.  However, the amount of
{  data which may be held within a connection is dependent on availability of
{  resources.  Thus the rate at which an application may send data is
{  ultimately limited by the rate at which the peer application receives data.
{
{    This request initiates a receive data operation, which transfers data into
{  the application's buffer from the connection.  The transfer of data into the
{  buffer is regulated by the availibilty of data from the connection.  Data is
{  accumulated in the application's buffer until the receive data operation
{  completes.
{
{    The receive data operation completes when one of the following conditions
{  occurs:
{
{      - A complete message (or a partial message which completes a message)
{        has been received.
{
{      - The specified buffer is full.
{
{      - The peer application has performed some operation other than sending
{        data.
{
{    Each receive data operation transfers a partial or complete message to the
{  application's buffer.  A partial message may be transferred under the
{  following conditions:
{
{      - The specified buffer is too small to contain the entire message.
{
{      - The peer application performs an interrupt operation or a synchronize
{        operation which does NOT synchronize the transfer of data FROM the
{        peer application.  Note that a partial message may be transferred even
{        if the peer application performs the synchronize operation after
{        sending a complete message.
{
{      - The connection is terminated by the peer application after sending a
{        partial message.
{
{      - The connection is terminated by the network.
{
{  If a partial message is transferred as a result of either of the first two
{  conditions, then the remainder of the message will be transferred by
{  subsequent receive data operations.
{
{    Since the receive data operation transfers data into the application's
{  buffer as it becomes available, arbitrarily large messages may be received
{  over a connection.  There is no need for an application to receive a large
{  message as a series of partial messages, each of which is small enough to be
{  held entirely within a connection at some instant in time, and concatenate
{  the partial messages to form the complete message.
{
{    However, an application may choose to receive partial messages by
{  specifying a buffer size smaller than the size of the message to be received.
{  For instance, receiving partial messages might be desirable in cases where it
{  is inconvenient to receive the entire message in memory at one time.
{
{    NOTE: The partial message boundaries identified when a message is received
{  are determined solely by the interaction between the NAM and the receiving
{  application; they do not indicate partial message boundaries (if any)
{  established by the peer application when the message was sent.
{
{    The calling task specifies whether it is to be suspended until the receive
{  data operation is complete or execute concurrently with the data transfer.
{  If the data transfer is to occur concurrently with task execution, the
{  application's buffer must be left intact until the transfer is complete.
{
{    A receive data operation may not be initiated if there is already a
{  receive data operation in progress for the connection or a task is waiting
{  for data to become available on the connection.  A request to initiate a
{  receive data operation under either of these conditions results in abnormal
{  status with the condition nae$receive_outstanding, if the calling task is to
{  execute concurrently with the data transfer.  However, if the calling task is
{  to be suspended, the request waits for the condition to clear and then
{  initiates the receive data operation.  In this case, the data transfer
{  timeout includes the interval while the request is waiting to initiate the
{  operation.
{
{    If the file is closed while a concurrent receive data operation is
{  outstanding, the operation is cancelled (but the ACTIVITY_STATUS parameter is
{  not updated).  This leaves the connection in an indeterminate state, since
{  the amount of data transferred from the connection is unknown.  The
{  connection should be synchronized before further usage.
{
{    Note that the STATUS parameter indicates the status of the request to
{  initiate the receive data operation, while the ACTIVITY_STATUS parameter
{  indicates the status of the receive data operation itself.  The caller must
{  examine both parameters to determine if the requested operation has been
{  successfully performed.
{
{    WARNING: An application must receive data which has been sent by the peer
{  application within a reasonable amount of time.  If available data
{  accumulates in the connection over an extended period of time, the NAM
{  terminates the connection.
{
{        NAP$SE_RECEIVE_DATA (FILE_IDENTIFIER, BUFFER, WAIT, PEER_OPERATION,
{          ACTIVITY_STATUS, STATUS)
{
{  FILE_IDENTIFIER: (input) This parameter specifies the file access identifier
{        established when the network file was opened.
{
{  BUFFER: (input) This parameter specifies a list of address/length pairs
{        defining the buffer where data is to be delivered.
{
{  WAIT: (input) This parameter specifies the action to be taken while waiting
{        for the receive data operation to complete.  The permitted values and
{        the corresponding actions are:
{
{          osc$wait: The calling task is suspended until the receive data
{            operation is complete.
{
{          osc$nowait: The calling task executes concurrently with the receive
{            data operation.  The osp$await_activity_complete request may be
{            used to wait for the data transfer to complete.
{
{            The lifetimes of the variables specified by the PEER_OPERATION and
{            ACTIVITY_STATUS parameters and the lifetime of the buffer
{            specified by the BUFFER parameter must exceed the duration of the
{            interval until the data transfer completes.
{
{            If another receive data operation is outstanding on the same
{            connection, the request will return abnormal status with the
{            condition nae$receive_outstanding.
{
{  PEER_OPERATION: (output) This parameter specifies the operation performed by
{        the peer application which caused the receive data operation to
{        complete.  The possible values and the corresponding meanings are:
{
{          nac$se_send_data: This value indicates that peer application
{            performed a send data operation and data has been delivered to the
{            application's buffer.
{
{            In this case the parameter value contains the following
{            sub-fields:
{
{              end_of_message: This field specifies whether the received data
{                completes a message.  If TRUE, the received data is either a
{                complete message or a partial message which completes a
{                message, depending on whether the preceding data received over
{                the connection completed a message.  If FALSE, the received
{                data is a partial message and the remainder of the message is
{                to be received by subsequent receive data operations.
{
{              qualified_data: This field specifies whether the received data
{                was marked as "qualified" by the sender.
{
{              data_length: This field specifies the length (in bytes) of the
{                received data.
{
{          nac$se_interrupt: This value indicates that the peer application
{            performed an interrupt operation.
{
{            In this case the parameter value contains the following
{            sub-fields:
{
{              interrupt_data_length: This field specifies the length (in
{                bytes) of the data sent with the interrupt.
{
{              interrupt_data: This field contains the data sent with the
{                interrupt.
{
{          nac$se_synchronize: This value indicates that the peer application
{            performed a synchronize operation.
{
{            In this case the parameter value contains the following
{            sub-fields:
{
{              direction: This field specifies the direction(s) in which the
{                transfer of data has been synchronized.  The possible values
{                and their meanings are:
{
{                  nac$se_synchronize_send_data: The transfer of data to the
{                    peer application has been synchronized.
{
{                  nac$se_synchronize_receive_data: The transfer of data from
{                    the peer application has been synchronized.
{
{                  nac$se_synchronize_all_data: The transfer of data to and from
{                    the peer application has been synchronized.
{
{                If send data has been synchronized, the application must
{                perform a synchronize_confirm operation in order to permit
{                data transfer to continue.  Until the synchronization is
{                confirmed, an attempt to initiate a send data operation
{                results in abnormal status with the condition
{                nae$se_synchronize_in_progress.
{
{                If only receive data has been synchronized, no confirmation is
{                required (or allowed).  Notification of receive data
{                synchronization is solely for informational purposes.
{
{              synchronize_data_length: This field specifies the length (in
{                bytes) of the data sent by the peer application via the
{                synchronize operation.
{
{              synchronize_data: This field contains the data sent by the peer
{                application via the synchronize operation.
{
{          nac$se_synchronize_confirm: This value indicates that the peer
{            application performed a synchronize_confirm operation.
{
{        The value of this parameter is not meaningful until the
{        ACTIVITY_STATUS parameter indicates that the receive data operation is
{        complete.
{
{  ACTIVITY_STATUS: (output) This parameter specifies the status of the receive
{        data operation.  The specified variable has the following fields:
{
{          complete: A boolean value which specifies whether the operation is
{            complete.
{
{          status: A status value which specifies the completion status of the
{            operation.  This value is not meaningful unless the operation is
{            complete.
{            CONDITIONS:
{                  nae$connection_terminated
{                  nae$data_transfer_timeout
{
{  STATUS: (output) This parameter specifies the request status.
{        CONDITIONS:
{              ame$improper_device_class
{              ame$improper_file_id
{              ame$ring_validation_error
{              nae$connection_terminated
{              nae$data_transfer_timeout
{              nae$improper_protocol
{              nae$receive_outstanding
{              {other BAM conditions}
{
