Formatos de mensaje de FMI
En esta sección se describen los formatos de mensaje para la interfaz de administración de funciones (FMI). Los formatos de mensaje se presentan en una notación independiente del idioma. Los detalles de la notación de formato de mensaje y las suposiciones clave sobre el contenido de los formatos de mensaje son los siguientes:
Reservado indica que el campo está establecido en cero (para un campo numérico) o todos los valores NULL (para nombres) por el remitente del mensaje.
Undefined indica que el valor del campo es indeterminado. El remitente no establece el campo y el receptor del mensaje no debe examinarlo.
Los campos que ocupan dos bytes, como opresid en la solicitud Open(PLU), se representan con el byte más significativo aritméticamente en la dirección de bytes más baja, independientemente de la orientación normal utilizada por el procesador en el que se ejecuta el software. Es decir, el valor de 2 bytes 0x1234 tiene el 0x12 de bytes en la dirección de bytes más baja. Sin embargo, los campos siguientes son excepciones:
Los campos srci y desti de los encabezados de búfer se almacenan en el formato local de la aplicación que los asigna, ya que solo la aplicación que asigna debe interpretar estos valores.
Los campos iniciales y finales de los elementos siempre se almacenan en orientación de bajo byte y de alto byte (la orientación normal de un procesador Intel).
Los mensajes se componen de búferes que constan de un encabezado de búfer y cero o más elementos de búfer. Para obtener más información sobre los formatos de búfer, vea Mensajes.
Las aplicaciones deben asignar valores de índice únicos (I) para cada conexión LPI activa dentro del nodo. En concreto, la solicitud open(SSCP) debe ser diferente del índice de origen que envía en respuesta a Open(PLU). Además, no se debe usar cero como valor I. Un valor I de cero significa que el remitente del mensaje está invitando al destinatario del mensaje a asignar un valor I.
El campo inicial de cada elemento proporciona el desplazamiento del primer byte de datos del elemento después del campo trpad .
En el caso de las aplicaciones de aplicación de unidad no lógica (LUA), se iniciará 1 (los datos se inician en el byte después del campo trpad ), 10 (nueve bytes de relleno se incluyen entre el campo trpad y el inicio de los datos) o 13 (12 bytes de relleno se incluyen entre el campo trpad y el inicio de los datos).
Para las aplicaciones LUA, startd es 4 (tres bytes de relleno entre el campo trpad y el inicio de los datos) en el primer elemento de un mensaje y 13 (12 bytes de relleno) en los elementos posteriores.
El nodo local usa bytes adicionales para obtener información de encabezado adicional. Esto evita tener que copiar datos en un nuevo búfer al agregar esta información.
Dado que startd indica el índice en dataru a partir de 1, no 0, el primer byte de datos válidos siempre está en dataru[startd–1].
Si startd es mayor que endd, no hay datos válidos en el mensaje.
Todos los campos de dataru son de tipo CHAR, excepto cuando los comentarios indican lo contrario.
Tenga en cuenta que, cuando un elemento de búfer tiene un inicio de 1, 10 o 13, esto solo se aplica al elemento inicial de la cadena de elementos y los elementos posteriores de la cadena tienen un inicio de 1. Los mensajes con dos cadenas de elementos vinculados distintos en los formatos de mensaje (por ejemplo, Open(PLU) Request y Open(PLU) OK Response) tienen el campo inicial en los elementos al principio de las cadenas como el valor (1, 10 o 13) dado en el formato de mensaje y los campos iniciales de todos los demás elementos como 1.