MOVE de un campo PIC X(n) a un campo PIC 9(n), SC07

[alfhost]

cuando se hace un MOVE de un campo PIC X(n) a un campo PIC 9(n), aunque el origen sea alfabético, transforma el contenido adaptándolo al formato del campo destino, sin producir error.

Nos gustaría que mirases alguna forma de solucionar esto, quizás alguna opción del Cobol para que se produjera un Abend

En cobol on-line y batch se produce la incidencia siguiente.
Si se mueven literales "a..z", "A..Z" y low values a variables numéricas [S9(26)] y luego se hace un "IF" del contenido no se produce el esperado ABEND.
Adjuntamos un documento con el código COBOL implementado junto con los "displays".
¡Low-values los convierte a ceros.

tras investigarlo llegó a la conclusión de que había que controlar por código el contenido de un campo alfanumérico antes de ser movido a un numérico. De lo contrario el comportamiento es impredecible: mover bien los números, transformar en basura, o incluso dar el deseado abend. Pero sin seguir un patrón fijo, al menos no uno simple y claro.

[tatindgp]

El aben SC07 es correct oque te pase, porque es un abend de datos:


0C7 Error de datos. Las causas mas corrientes son:

- Se ha intentado hacer una operacion aritmetica con un campo cu-
yo contenido no es numerico.

- Un campo numerico utilizado en una comparacion no contiene di-
gitos.

- Se ha intentado mover un campo cuyo contenido no es numerico.



SI queres mover un picx X a un pic 9 lo que tenes que hacer es asegurate de que el pix x tenga la misma losgitud que el pic 9 y que ademas el pic x este completamente informado por numeros, de lo contrario te dara el abend sc07, sino prueba converitr el pix x a un pic 9, completando con ceros los caracteres que no sean numericos, osea, letras, espacios, low-values, hig.values, etc, y luego lo mueves a un numerico. Esto lo puedes hacer recorriendo el pix x posicion por posicion y remplazando cada caracter, o sino, utilizar la uçinstruccion replace para reemplazar lo low-values, por ceros, alphabetics por ceros, etc.

[Ivan Pequeño Andrade]

Tal vez un Test con las siguientes funciones implícitas de Cobol podrían ayudar

If Var 9 Is Numeric
If Var X is Alfanumeric
posting.php?mode=reply&f=13&t=2094&sid=50d3bddfe0c5ed099adb6112b4f8973c#

[riloama]

Hola Alfhost,
siempre debes hacer un test de clase ( if variable is numeric ) porque no toda operacion aritmetica con datos no numericos da un S0C7.
Te paso un ejemplo de programa COBOL que podras compilar y ejecutar en tu instalación y en el que multiplicaremos ABC * 2 y obtendremos un resultado :

IDENTIFICATION DIVISION.
PROGRAM-ID. NOS0C7.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-VARIABLES.
05 WS-PARM.
10 WS-0 PIC X(03) VALUE 'ABC'.
10 WS-1 REDEFINES WS-0 PIC 9(03).
10 WS-2 PIC 9(03).
PROCEDURE DIVISION.
COMPUTE WS-2 = WS-1 * 2
DISPLAY 'WS-0: ' WS-0
DISPLAY 'WS-1: ' WS-1
DISPLAY 'WS-2: ' WS-2
STOP RUN.

Al ejecutarlo, los displays dan lo siguiente
WS-0: ABC
WS-1: ABC
WS-2: 246

Este programa funciona correctamente y efectivamente el resultado de multiplicar la WS-1 cuyo contenido es 'ABC' por 2 da el numero 246.
El tema es facil de observar en el assembler que genera la instruccion COMPUTE de COBOL.
000014 COMPUTE

PACK 240(3,13),0(3,8)
OI 242(13),X'0F'
MP 240(3,13),67(1,10)
UNPK 3(3,8),241(2,13)
OI 5(8),X'F0'

La clave esta en la instruccion PACK que transforma la supuesta variable numérica WS-1, pero que contiene el string ‘ABC’, en una variable interna empaquetada ( similar al COMP-3). Esto lo hace descartando los primeros ½ bytes de cada carácter sin verificar si corresponden a una configuración numérica.
ABC tiene la configuración hexadecimal

CCC
123

Por lo tanto si se descartan los medios bytes que contienen C se obtiene el numero 123; la siguiente instrucción OI garantiza que este numero es positivo ya que en la definición de la variable WS-1 no hay signo; luego multiplica esta variable interna empaquetada que contiene 123 por 2, que obviamente da como resultado 246; las dos instrucciones siguientes devuelven el valor 246 a la variable WS-2 desempaquetando la variable interna.
Como podras ver si compilas este programa y lo ejecutas, logramos multiplicar ABC * 2, no dio abend S0C7 y obtuvimos el resultado 246.

Este resultado es un exponente de una clase de operaciones similares que a priori se diria que no pueden ejecutarse pero que realmente generan resultados numericos, por lo que para asegurarte que tus calculos sean correctos si o si debes hacer el test de clase y preguntar si las variables numéricas poseen realmente números ( if variable is numeric ).

[alfhost]

Muchas gracias a todos, despues de estos correos sobre todo el de Riloama.

Os adjunto la Nota de IBM:


Invalid numbers fail to give ABEND0C7 data exception.



Technote (troubleshooting)

Problem(Abstract)
If garbage data appears in a numeric variable, I want an abend. Sometimes I get my desired abend, other times I get bad arithmetic results.



Cause
Sometimes bad data coincidently passes for valid numbers. By a quirk of the hardware or coincidence of the particular data, bad bytes may be wrongly used as numbers. You will not know that this happens and your arithmetic will produce wrong answers. At other times, bad bytes will cause ABEND0C7. You cannot rely on receiving ABEND0C7 all of the time.
The SC27-1408-04 Enterprise COBOL Language Reference, table 46, page 381 tells the permissible MOVEs.
Example of EBCDIC data where the letter b means a blank (hex 40):
02 ITEM1 PICTURE 9(5) VALUE "bbbb0".
02 ITEM2 PICTURE 9(5) VALUE "bbbbb".
Doing arithmetic on ITEM1 will work because of the IBM zSeries architecture's hardware even though it's against the COBOL rules. The low order number of X'F0' and has a valid sign which allows computions to run without failure.
ITEM2 will give ABEND0C7 because the low order number of X'40' does not contain a valid sign. Your situation will be more complex than this static example.


Resolving the problem
Numeric fields such as PICTURE 9 must contain numbers only. Any numeric variable that may contain bad data must be tested. For example use
IF ITEM1 IS NOT NUMERIC ...
That will test all the characters in the field.
There are two compiler options NUMPROC and NUMCLS that may appear to get around this but they too are unreliable solutions.
If you know that the data will contain numbers, a decimal point, and spaces, then the FUNCTION NUMVAL may be used to convert. But even that is not a substitute for the NUMERIC test.

[riloama]

Hola Alfhost,

la nota de IBM se ajusta perfectamente al comentario que te envie.

Con tecnicas similares a las expuestas podrias sumar JUAN + JOSE + MARIA + MARTA; en terminos menos exagerados algun dato numerico que ingrese a nuestro sistema puede tener alguna 'basura' no numerica; como no esta garantizado el S0C7, que en este y en todos los casos opera como una proteccion a nuestro sistema de datos, sino testeamos y rechazamos estaremos en problemas especialmente si luego nuestro dato queda registrado.