Compatibilidad de asignación en EGL

Las normas de compatibilidad de asignación se aplican en las situaciones siguientes:
La compatibilidad de asignación se basa en la siguiente clasificación de tipos:
Las normas de compatibilidad de asignación son las siguientes:
Nota: En los casos siguientes hay un conjunto de reglas distinto en vigor:

Para obtener detalles sobre estos casos, consulte el apartado Compatibilidad de referencia en EGL.

La situación al pasar datos a un programa es la siguiente:
  • Un programa llamado por EGL acepta una serie de bytes sin validación, excepto porque los datos recibidos se truncan o se rellenan de acuerdo con el tipo y la longitud del parámetro
  • Se producen errores si una sentencia EGL intenta utilizar datos cuyo formato no es válido en el contexto de la utilización intentada

Asignación en diversos tipos numéricos

Un valor de cualquiera de los tipos numéricos (incluidos NUMC y PACF) puede asignarse a un campo de cualquier tipo numérico y tamaño, y EGL realizará las conversiones necesarias para conservar el valor en el formato destino.

Se añaden o truncan ceros no significativos si es necesario. (Los ceros iniciales de la parte entera de un valor no son significativos, al igual que los dígitos finales de la parte fraccionaria de un valor).

Para cualquiera de los tipos numéricos, puede utilizar la variable de sistema sysVar.overflowIndicator para comprobar si una asignación o un cálculo numérico han provocado un desbordamiento aritmético, y puede establecer la variable de sistema VGVar.handleOverflow para especificar la consecuencia de tal desbordamiento.

Si se produce un desbordamiento aritmético, el valor del campo destino no cambia. Si no se produce un desbordamiento aritmético, el valor asignado al campo destino se alinea de acuerdo con la declaración del campo destino.

Supongamos que está copiando un campo de tipo NUM en otro y que el valor de tiempo de ejecución del campo origen es 108.314:
  • Si el campo destino permite siete dígitos con una posición decimal, el campo destino recibe el valor 000108.3, y no se detecta desbordamiento numérico. (Una perdida de precisión en un valor fraccionario no se considera desbordamiento).
  • Si el campo destino permite cuatro dígitos con dos posiciones decimales, se detecta un desbordamiento numérico y el valor del campo destino no cambia.

Cuando asigna un valor de coma flotante (tipo FLOAT o SMALLFLOAT) a un campo de un tipo de coma fija, el valor destino se trunca si es necesario. Si un valor origen es 108.357 y el destino de coma fija tiene un decimal, por ejemplo, el destino recibe 108.3.

Otras asignaciones de tipos cruzados

A continuación se ofrecen detalles acerca de otras asignaciones de tipos cruzados:
  • La asignación de un valor de tipo NUM a un destino de tipo CHAR sólo es válida si la declaración origen no tiene posiciones decimales. Esta operación es equivalente a una asignación de CHAR a CHAR.
    Si la longitud origen es 4 y el valor es 21, por ejemplo, el contenido es equivalente a "0021", y una discrepancia de longitudes no provoca una condición de error:
    • Si la longitud del destino es 5, el valor se almacena como "0021 " (se añade un espacio de un solo byte a la derecha)
    • Si la longitud del destino es 3, el valor se almacena como "002 " (se trunca un dígito a la derecha)

    Si el valor de tipo NUM es negativo y se asigna a un valor de tipo CHAR, el último byte copiado en el campo es un carácter no imprimible.

  • La asignación de un valor de tipo CHAR a un destino de tipo NUM sólo es válida en el caso siguiente:
    • El origen (un campo o expresión de serie) contiene dígitos sin otros caracteres
    • La declaración destino no tiene posiciones decimales

    Esta operación es equivalente a una asignación de NUM a NUM.

    Si la longitud origen es 4 y el valor es "0021", por ejemplo, el contenido es equivalente a un 21 numérico; en los siguientes ejemplos se muestra el efecto de una discrepancia de longitudes:
    • Si la longitud del destino es 5, el valor se almacena como 0021 (se añade un cero numérico a la izquierda)
    • Si la longitud del destino es 3, el valor se almacena como 021 (se trunca un dígito no significativo)
    • Si la longitud del destino es 1, el valor se almacena como 1
  • La asignación de un valor de tipo NUMC a un destino de tipo CHAR es posible en dos pasos, lo que elimina el signo si el valor es positivo:
    1. Asigne el valor NUMC a un destino de tipo NUM
    2. Asigne el valor NUM a un destino de tipo CHAR

    Si el valor del destino de tipo NUMC es negativo, el último byte copiado en destino de tipo CHAR es un carácter no imprimible.

  • La asignación de un valor de tipo CHAR a un destino de tipo HEX sólo es válida si los caracteres del origen están dentro del rango de dígitos hexadecimales (0-9, A-F, a-f).
  • La asignación de un valor de tipo HEX a un destino de tipo CHAR almacena dígitos y letras mayúsculas (A-F) en el destino.
  • La asignación de un valor de tipo MONEY a un destino de tipo CHAR no es válida. El procedimiento recomendado para convertir desde MONEY a CHAR consiste en utilizar la función del sistema strLib.formatNumber.
  • La asignación de un valor de tipo NUM o CHAR a un destino de tipo DATE solo es válida si el valor origen es una fecha válida de acuerdo con la máscara aaaaMMdd; para obtener detalles, consulte el tema DATE.
  • La asignación de un valor de tipo NUM o CHAR a un destino de tipo TIME solo es válida si el valor fuente es una hora válida de acuerdo con la máscara hhmmss; para obtener detalles, consulte el tema TIME.
  • La asignación de un valor de tipo CHAR a un destino de tipo TIMESTAMP solo es válida si el valor origen es una indicación de la hora válida de acuerdo con la máscara del campo TIMESTAMP. A continuación se ofrece un ejemplo:
       // NO válido porque el 30 de febrero no es una fecha válida
       myTS timestamp("aaaaMMdd"); 
       myTS = "20050230";
    Si faltan los caracteres iniciales de una máscara completa (por ejemplo, si la máscara es "dd"), EGL supone que los caracteres de nivel superior ("aaaaMM", en este caso) representen el momento actual, de acuerdo con el reloj del sistema. Las sentencias siguientes originan un error de tiempo de ejecución en febrero:
       // NO válido si se ejecuta en febrero
       myTS timestamp("dd"); 
       myTS = "30";
  • La asignación de un valor de tipo TIME o DATE a un destino de tipo NUM es equivalente a una asignación NUM a NUM.
  • La asignación de un valor de tipo TIME, DATE o TIMESTAMP a un destino de tipo CHAR es equivalente a una asignación CHAR a CHAR.

Relleno y truncamiento en tipos de caracteres

Si el destino es de tipo carácter no STRING (incluidos DBCHAR y HEX) y tiene más espacio que el necesario para almacenar un valor origen, EGL lo rellena con datos por la derecha:
  • Utiliza blancos de un solo byte para rellenar un destino de tipo CHAR o MBCHAR
  • Utiliza blancos de doble byte para rellenar un destino de tipo DBCHAR
  • Utiliza blancos de doble byte Unicode para rellenar un destino de tipo UNICODE
  • Utiliza ceros binarios para rellenar un destino de tipo HEX, lo que significa (por ejemplo) que un valor origen "0A" se almacena en un destino de doble byte como "0A00" en lugar de "000A"

EGL trunca los valores por la derecha si el destino de un tipo de carácter no tiene espacio suficiente para almacenar el valor origen. No se indica ningún error.

Si el parámetro es una serie de longitud limitada, se aplican las reglas siguientes:
  • Si en el origen hay más caracteres que los que son válidos en el destino, el entorno de ejecución de EGL trunca el contenido copiado para que quepa en la longitud disponible.
  • Si en el origen hay menos caracteres que los que son válidos en el destino, el entorno de ejecución de EGL rellena con blancos el contenido copiado hasta la longitud de la serie destino. Sin embargo, los blancos finales de una serie de longitud limitada se ignoran durante una comparación.
La siguiente situación representa un caso especial:
  • La plataforma de entorno de ejecución da soporte al juego de caracteres EBCDIC
  • La sentencia de asignación copia un literal de tipo MBCHAR o un elemento de tipo MBCHAR en un elemento más corto de tipo MBCHAR
  • Un truncamiento byte por byte eliminaría un carácter de desplazamiento a teclado estándar final o dividiría un carácter DBCHAR

En esta situación, EGL trunca los caracteres según sea necesario para asegurarse de que el elemento destino contiene una serie válida de tipo MBCHAR y, a continuación, añade (si es necesario) blancos de un solo byte al final.

Asignación entre indicaciones de la hora

Si asigna un elemento de tipo TIMESTAMP a otro campo de tipo TIMESTAMP, se aplican las normas siguientes:
  • Si a la máscara del campo origen le faltan entradas de un nivel relativamente alto necesarias para el campo destino, las entradas de destino correspondientes se asignan de acuerdo con el reloj del sistema en el momento de la asignación, tal como se muestra en estos ejemplos:
    •   sourceTimeStamp timestamp ("MMdd");
      	 targetTimeStamp timestamp ("aaaaMMdd");
      	
      	 sourceTimeStamp = "1201";
      
        // si este código se ejecuta en 2004, la sentencia siguiente
        // asigna 20041201 a targetTimeStamp
      	 targetTimeStamp = sourceTimeStamp; 
    •   sourceTimeStamp02 timestamp ("ssff");
        targetTimeStamp02 timestamp ("mmssff");
      	
      	 sourceTimeStamp02 = "3201";
      
        // la asignación siguiente incluye el minuto
        // en el que se ejecuta la sentencia de asignación
        targetTimeStamp02 = sourceTimeStamp02;
    • Si a la máscara del campo origen le falta entradas de nivel relativamente bajo necesarias para el campo destino, a las entradas de destino correspondientes se les asignan los valores válidos más bajos, tal como muestran estos ejemplos:
      • sourceTimeStamp timestamp ("aaaaMM");
        targetTimeStamp timestamp ("aaaaMMdd");
        
        sourceTimeStamp = "200412";
        
        // independientemente del día, la sentencia siguiente
        // asigna 20041201 a targetTimeStamp
        targetTimeStamp = sourceTimeStamp; 
      • sourceTimeStamp02 timestamp ("hh");
        targetTimeStamp02 timestamp ("hhmm");
        
        sourceTimeStamp02 = "11";
        
        // independientemente del minuto, la sentencia siguiente
        // asigna 1100 a targetTimeStamp02
        targetTimeStamp02 = sourceTimeStamp02;

Asignación hacia o desde elementos subestructurados de estructuras fijas

Puede asignar un campo subestructurado a un campo no subestructurado o a la inversa, y puede asignar valores entre dos campos subestructurados. Supongamos, por ejemplo, que las variables denominadas myNum y myRecord se basan en los siguientes componentes:

  DataItem myNumPart
    NUM(12)
  end

  Record ExampleRecordPart type basicRecord
    10 topMost CHAR(4);
      20 next01 HEX(4);
      20 next02 HEX(4);
  end

La asignación de un valor de tipo HEX a un elemento de tipo NUM no es válida fuera de las variables matemáticas del sistema; pero una asignación en el formato myNum = topMost es válida, debido a que topMost es de tipo CHAR. En términos generales, los tipos primitivos de los campos de una sentencia de asignación guían la asignación, y los tipos primitivos de los elementos subordinados no se tienen en cuenta.

El tipo primitivo de un elemento subestructurado es de tipo CHAR por omisión. Si asigna datos hacia o desde un campo subestructurado y no especifica un tipo primitivo diferente durante la declaración, las normas descritas anteriormente para los campos de tipo CHAR estarán en vigor durante la asignación.

Asignación de un registro fijo

La asignación de un registro fijo a otro es equivalente a la asignación de un elemento subestructurado de tipo CHAR a otro. Una discrepancia de longitudes añade blancos de un solo byte a la derecha del valor recibido o elimina caracteres de un solo byte a la derecha del valor recibido. La asignación no tiene en cuenta los tipos primitivos de los campos de estructura subordinados.

Se aplican las siguientes excepciones:
  • El contenido de un registro puede asignarse a un registro o a un campo de tipo CHAR, HEX o MBCHAR, pero no a un campo de ningún otro tipo
  • Un registro puede recibir datos de un registro, de un literal de serie o de un campo de tipo CHAR, HEX o MBCHAR, pero no de un literal numérico ni de un campo de un tipo que no sea CHAR, HEX o MBCHAR

Finalmente, si asigna un registro SQL hacia o desde un registro de un tipo diferente, debe asegurarse de que el registro no SQL tenga espacio suficiente para el área de cuatro bytes que precede a cada campo de estructura.

Conceptos relacionados
PageHandler

Comentarios
(C) Copyright IBM Corporation 2000, 2005. Reservados todos los derechos.