|
Hola @fastpho, ya no me da ese error, el "linkado" lo hace sin problemas, pero al ejecutar la prueba que has puesto no me hace nada, es más da un error "Exception Number : UNDEFINED_EXCEPTION(C000041D)"
No sé si puede ser porque, si transformo el valor X"80000001" que has puesto a una variable s9(9), falta un dígito para que quepa, (X"80000001" = *2.147.483.649, 10 dígitos), y quizás debería ser una variable S9(10), porque yo, en el ejemplo que me envió en su día Rapinto, no usaba ese valor para HKCU, si no X"01000080". Aunque ésta vez, sí he estado mirando en muchas más páginas por internet y el valor que pones tú es el correcto. (Ya sé que tú en el ejemplo has puesto X"80000002" que es HKLM, pero yo necesito que sea X"80000001", que es HKCU) Gracias y perdona las molestias. Un salu2.- |
Hola @Josber
@Rapinto lo definio asi porque era un "capo" :) entonces se hara como rapinto dice Código COBOL:
haciendo un display a HKEY-CURRENT-USER nos da 2.147.483.649 pasale este valor como VALUE Código COBOL:
Probalo a ver como sale Saludos... |
3 Archivos Adjunto(s)
@Josber, Este ejemplo esta probado y funciona bien :yupi: , el post #12 explotaba:tonto:
Código COBOL:
Código COBOL:
|
A ver chavalería, los COMP-5 son binarios nativos, es decir que los PIC de Cobol no tiene efecto directo, sólo son indican cuantos bytes tiene el campo dividiendo el PIC por 2. O sea que un PIC S9(9) COMP-5 es un Integer nativo y puede almacenar valores de 10 posiciones: Un PIC S9(9) COMP-5 puede almacenar desde -2,147,483,648 hasta 2,147,483,647 y un PIC 9(9) COMP-5 (sin signo) desde 0 hasta 4,294,967,295
También no hace falta invertir los valores de HKLM y HKCU, simplemente hay que definirlos directamente en binario nativo: Código COBOL:
Si la máquina es Little-Endian, ya hará la inversión automáticamente. Así este código funcionaría sobre una máquina Big-Endian sin tener que modificarlo. Si definimos los valores en alfanumérico con un REDEFINES, no habrá inversión y así limitamos el código a máquinas Little-Endian sólo. |
@fastpho, el post Nº12 explota porque el PIC S9(10) COMP-5 es tomado por un Big Integer de 8 bytes, es lo mismo como si hubieras definido PIC S9(18) ;)
|
Cita:
Código COBOL:
sigue teniendo el mismo problema, (te lo digo porque acabo de probarlo), ocupa 10 posiciones y el máximo son 9, (ya sé que puede almacenar un valor superior pero, si bajo el número a 9 posiciones, decimal 999.999.999, hexadecimal *3B9AC9FF, no da problemas al compilar, no sé si será tema de alguna directiva que haya que ponerle al precompilador o algo por el estilo), por lo que al compilar, da el error JMN2034I-S The numeric literal of the VALUE clause specifies a value which is truncated to zero. Figurative constant ZERO is assumed. La única manera es como ha puesto @fastpho, que es como lo hacía yo antes, y, es como si fuera una transformación de Little_endian a Big_endian, pero quitándole una posición ¿?¿?¿?, que es lo que no entiendo. Lo de limitar el código a máquinas Little_endian, la mayoría son con procesadores Intel, y no habrá problemas, porque es el sistema suyo de facto, no sé ahora, qué procesadores usan Big_endian, pero, te aseguro que no es mi caso. Un salu2 y mil gracias.- |
@Josber, se nota que llevo años sin tocar Fujitsu, estoy con Micro Focus y ahí sí que es como lo decía. Es decir que un COMP-5 acepta valores superiores a 9 posiciones, cosa que me parece normal ya que se trata de un binario nativo. Físicamente los valores de 10 posiciones entran, si no de hecho lo del REDEFINES no funcionaría. Lo que pasa es que hay que "engañarlo" asignando el valor byte por byte en un campo alfanumérico.
Una burrada la verdad, y eso que me encanta el compilador de Fujitsu. He hecho tests, porque está ahí el tipo BINARY-LONG, que me he dicho lo mismo hay que usar este, que equivale a PIC S9(9) COMP-5. Pero dice que es signado, y si le pongo UNSIGNED como dice el manual, el compilador insulta con un error y no compila :D Vamos, que es un fallito de los de Fujitsu, pero bueno, mientras que haya solución. Os he mareado para nada chavales, lo siento ;) |
Hola @Josber, @Kuk,
La explicacion de la solucion no estaria en las posiciones ..... si 9 o 10 etc esta en que la representacion de las variables en cuestion que son de 4 bytes (80 00 00 01) = HKEY-CURRENT-USER y de ahi que funciona perfectamente el REDEFINES declarando como PIC 9(9) COMP-5 para representar los 4 bytes necesarios PIC X(4). Código:
1 a 4 digitos son 2 bytes = PIC 9(4) COMP-5The size of the storage area allocated to a binary item is determined as follows by the number of digits specified by a PICTURE clause. 1 to 4 digits: 2 bytes 5 to 9 digits: 4 bytes 10 to 18 digits: 8 bytes Esta declaracion tipo BINARY-SHORT BINARY-LONG BINARY-DOUBLE en power-cobol 5.0 no existe me parece que las pusieron en fujitsu cobol 9.00 como para moderninzarlo pero sigue siendo Código COBOL:
Saludos ... |
@fastpho, no da error al compilar como tú dices, pero por ejemplo
Código COBOL:
al no coger bien por no aceptar más de 9 posiciones, en éste caso HKCU, en vez de tener el valor 2.147.483.649, que es el que le corresponde en el REDEFINES, se trunca al valor 016.777.344, (según el QUICK-WATCH del debuger), y no funciona correctamente el programa, a pesar de que, por lo que he podido comprobar, ese es el valor que tengo yo que usar para que me funcione, es lo que vengo diciendo, Código COBOL:
es de la única manera que he conseguido que funcione sin problemas, porque de éstas dos maneras, no funciona, con signo y sin signo, es igual Código COBOL:
Al final, he conseguido lo que quería, pero, me tiene "enmarranao" el tema y, por internet no hay mucha info al respecto. Un salu2.- |
@Josber, te estás liando por lo de Endianess. No te olvides de que al usar COMP-5 que es un binario dependiente de la máquina, binario nativo, es el sistema el que se encarga de almacenarlo en memoria como corresponda que para Little-Endian el valor h"80000001" se almacena como h"01000080" por lo de Endianess.
Pero cuando hacemos REDEFINES no se hace almacenamiento sino un mapeo directo sobre algo que ya está almacenado en memoria. Así que si le pones el valor x"80000001" en un campo alfanumérico y lo redefines en COMP-5, el sistema no lo vuelve a almacenar según el orden correspondiente a Little-Endian (que para Little-Endian en memoria debe estar como x"01000080"). Así que el valor que te dará es el inverso por byte. Resumiendo, el valor en decimal de esto: Código COBOL:
Es 16.777.344 porque en memoria va almacenado en este orden 80 00 00 01 pero como la máquina es Little-Endian empezará por el último byte que contiene 01 y lo leera como 01 00 00 80 que da el valor 16.777.344 en vez de 2.147.483.649 que tú necesitas. No sé si me explico. Total, ejecuta este código, ya verás: Código COBOL:
|
| La franja horaria es GMT +2. Ahora son las 15:44. |
Powered by: vBulletin, Versión 3.8.7
Derechos de Autor ©2000 - 2026, Jelsoft Enterprises Ltd.