1. Si se define la variable de entorno DBPATH conteniendo el directorio en curso, a la hora de seleccionar la base de datos ya no aparecerá dos veces con el mismo nombre.
2. En la versión de SSK ya funciona la cláusula "lc" para recoger el número de serie de Trans.
$ trans -lc
trans - Serie : xxxx
Este comando nos puede servir para serializar nuestras propias bases de datos.
3. El comando TBCHECK que se incorporaba en versiones anteriores se ha sustituido por tres comandos nuevos, que realizan el mismo trabajo aunque de manera diferente, resultando más rápido y eficiente.
De hecho, en el comando "trans" (Entorno de Desarrollo), en las opciones "Reparar Tabla" y "Chequear Tabla", se han conectado estos nuevos comandos en lugar del "tbcheck". Al menú de desarrollo se han añadido dos nuevas opciones en la misma persiana ("Chequear Base de Datos" y "Listar Chequeos"). Estas opciones también están llamando a los nuevos comandos que se explican en este documento.
Estos comandos son los siguientes:
A continuación se explica en detalle el funcionamiento de estos comandos.
IMPORTANTE
—Todos los programas desarrollados con versiones anteriores de TransTOOL
deberán ser recompilados con la versión 3.0.07 para su correcto
funcionamiento.
—Una tabla no puede ser reparada simultáneamente por distintos procesos.
Este comando comprueba el estado de un fichero de índices de una tabla de la base de datos. Su sintaxis es cualquiera de las siguientes:
tchkidx nombre_base_datos nombre_tabla
tchkidx nombre_base_datos -all
En el primer caso chequeará la tabla indicada por "nombre_tabla" de la base de datos indicada por "nombre_base_datos".
En el segundo caso chequeará todas las tablas de la base de datos indicada por "nombre_base_datos".
En "nombre_base_datos" se deberá indicar el PATH completo de la B.D., en el caso de no estar ejecutando el comando en el directorio que contiene al directorio de la base de datos, es decir, este comando no utiliza la variable de entorno DBPATH para localizar la base de datos que se indique.
En el caso de encontrar errores para una tabla determinada, añadirá una entrada para la tabla correspondiente a un fichero de catálogo nuevo de nombre "syserror".
El SQL (comando "tsql"), revisará este nuevo fichero de catálogo (syserror) cada vez que le llegue una instrucción de apertura de una B.D. (instrucción "database"). Si encontrase errores para alguna de las tablas de dicha base de datos, enviará un aviso al comando que lo llamó (trans, t4gl, tform o treport). Este comando, al recibir el mensaje, enviará otro al terminal indicando el problema y recomendando la NO utilización de la base de datos hasta su reparación.
Si a pesar de la recomendación el operador decide continuar trabajando sobre la B.D., el comando en ejecución escribirá una entrada en un nuevo fichero de catálogo de nombre "sysmonitor", indicando el nombre del usuario, la fecha, la hora y el comando que se ejecutó a pesar de la recomendación.
Este comando se encarga de la generación de un nuevo fichero de índices para una tabla de la base de datos a partir de la información contenida en el catálogo del sistema. Su sintaxis es la siguiente:
trepidx nombre_base_datos nombre_tabla
Una vez terminada con éxito la generación del nuevo fichero de índices, borrará del fichero "syserror" la entrada, indicadora del error, correspondiente a la tabla reparada.
Este comando realiza además una compactación de la tabla para la que se regenera el fichero de índices. Por razones de seguridad, para poder ejecutarlo necesitará espacio libre en el mismo "file system" en que se encuentre la tabla a reparar. El espacio libre que necesitará para realizar la operación será, como máximo, igual al tamaño que ocupe el fichero de datos (.dat) de la tabla que se está reparando. Caso de no tener espacio suficiente, el comando enviará un mensaje al operador y no ejecutará.
Este comando utiliza una estrategia determinada para reparar una tabla de índices; si no consiguiera repararla automáticamente, intentará una segunda estrategia, aunque más lenta que la primera. La primera estrategia es la siguiente:
1. Comprueba la existencia de espacio suficiente en el "file system" donde se encuentre la tabla a reparar.
2. Compara la longitud de registro indicada por el catálogo del sistema con la que encuentre en la cabecera del fichero de índices. Caso de ser distintas indicará al operador que considerará como buena la indicada por el catálogo de la base de datos y pedirá confirmación para continuar. Si la longitud de registro elegida por el comando no fuese la correcta será porque la tabla "systables" del catálogo del sistema esté en malas condiciones; no siga con la ejecución del comando e intente la recuperación de la tabla por el método UNLOAD-LOAD que se explica más adelante.
3. Crea una tabla temporal, de nombre igual al de la tabla a reparar, pero con nombre en mayúsculas y extensión ".dat" (a partir de ahora nos referiremos a esta tabla como "MAYUSCULAS.dat").
4. Copia una a una todas la tablas no borradas de la tabla "MAYUSCULAS.dat". Durante esta fase mostrará el mensaje: "Compactando…".
5. Crea un "MAYUSCULAS.idx" vacío (sólo con la información de cabecera) con la información contenida en el "sysindexes" para la tabla que se está reparando.
6. Copia este fichero de índices vacío sobre el fichero de índices original de la tabla a reparar. Esto se hace con el fin de recuperar el espacio que ocupase el fichero de índices defectuoso y no dejar la tabla original sin fichero de índices.
7. Añade los índices sobre el temporal.
8. Mueve las temporales sobre las originales, es decir, mueve el "MAYUSCULAS.dat" y el "MAYUSCULAS.idx" sobre el ".dat" y el ".idx" originales.
Si al ejecutar la etapa "7" se encontrase algún error, el comando enviará el mensaje "Fase 2" al terminal y comenzará una nueva estrategia de reparación que explicamos a continuación:
8. Vuelve a crear el "MAYUSCULAS.dat" y el "MAYUSCULAS.idx" vacíos.
9. Lee registro a registro del "nombre_tabla.dat" original y, para cada registro, graba en el "MAYUSCULAS.dat" y añade el índice correspondiente en el "MAYUSCULAS.idx". Cada fila para la que no pueda realizar esta operación será descargada sobre un fichero de nombre el de la tabla original en mayúsculas y extensión ".UNL" (a partir de ahora "MAYUSCULAS.UNL"). Esto podría ser debido a la existencia de claves duplicadas para índices únicos, lo cual se podría haber provocado trabajando sobre la tabla con el fichero de índices en mal estado.
10. Una vez terminada la operación comprueba que el número de filas descargadas sobre el fichero "MAYUSCULAS.UNL" no sea superior al 10% del número total de filas de la tabla. Si fuese superior a dicho porcentaje pediría confirmación antes de mover las temporales sobre las originales. Por el contrario, si es inferior moverá los ficheros temporales "MAYUSCULAS.dat" y "MAYUSCULAS.idx" sobre los originales y terminará el proceso. Si fuese superior al 10% y se diese confirmación, se moverán los ficheros temporales sobre los originales y terminará el proceso. En el caso de que no se diese confirmación, se borrarían las tablas temporales y se dejarían los originales como estuvieran, con lo cual, se deberá intentar la recuperación por el procedimiento UNLOAD-LOAD que se explica más adelante.
Este comando siempre supone que la información contenida en el catálogo del sistema (exactamente en las tablas de catálogo, "systables", "syscolumns" y "sysindexes") es correcta, es decir, que el contenido del fichero "nombre_tabla.dat" es consistente con la información del catálogo. Los problemas que se han explicado más arriba, sólo pueden producirse en el caso de que esta consistencia no se cumpla.
Este comando permite listar los ficheros "syserror" y "sysmonitor". Su sintaxis es la siguiente:
tlisterr nombre_base_datos [[-m][-e][-c]
Opciones:
-m: Proporciona una lista de los accesos realizados sobre una base de datos que tuviese algún fichero de índices estropeado. Indicará el nombre del usuario, la fecha, la hora y el programa que lo hizo.
-e: Proporciona una lista de los errores reportados por el comando "tchkidx". El comando "trepidx" borrará todas las entradas correspondientes a una tabla determinada una vez reparada correctamente.
-c: Proporciona una lista de los chequeos y reparaciones realizados sobre las distintas tablas de la base de datos.
Si no se indica ninguna de las tres opciones proporcionará las tres listas.
Al igual que en casos anteriores, "nombre_base_datos" debe indicar el PATH completo de la B.D.
Se ha añadido una entrada nueva en la persiana de "Diccionario" del comando "trans" que permite la ejecución de este comando, dicha opción es "Listar Chequeos".
1. Existe otro mecanismo para regenerar un fichero de índices una vez detectado un error. Dicho mecanismo consiste en:
a) Realizar un UNLOAD de la tabla,
b) borrarla,
c) crearla de nuevo,
d) hacer un LOAD,
e) volver a crear los índices.
En el caso de no conseguir recuperar la tabla por este mecanismo, si se invierte el orden en los pasos "d)" y "e)" se recuperará con toda seguridad, pero el método resultará más lento que el anterior.
Este mecanismo tampoco actuará sobre el fichero "syserror", por lo cual podría existir una entrada en el mismo para la tabla que acaba de reparar. Si está seguro de que todas las tablas indicadas en el fichero "syserror" han sido convenientemente corregidas, puede borrarlo, con lo cual dejarán de salir mensajes de error en los terminales que trabajen con la base de datos.
2. Uno de los motivos que puede corromper un fichero de índices de una tabla de la base de datos es una caída de la máquina. Por lo tanto, en el momento de arrancar la máquina de nuevo, es absolutamente necesaria la revisión de la consistencia de las bases de datos que estuvieran en funcionamiento en el momento de la caída.
3. Si por cualquier motivo tuviese que abortar un proceso por medio del comando "kill" del sistema operativo, dicho comando no lo deberá lanzar nunca sobre el servidor de la base de datos (comando "tsql") sino sobre el proceso que lo lanzó (proceso "padre"), que sólo podrá ser uno de los siguientes: tform, treport, t4gl o trans.
4. El fichero "sysmonitor", en el que se almacenan los datos correspondientes al uso de una base de datos en malas condiciones, no es borrado por ninguno de los comandos de TransTOOL. El administrador de la base de datos podrá borrarlo cuando lo considere oportuno.
1. Después de la instrucción AFTER ADD OF TABLA ya se puede especificar una instrucción UPDATE de la misma fila insertada sin que se produzca un error de bloqueo.
2. Cuando se define una columna con LOOKUP y * para cuidar la integridad de datos, a la hora de modificar no lo permite si el nuevo valor no existe en la tabla de cruce.
3. Posibilidad de crear tablas temporales en un programa tform mediante la cláusula INTO TEMP de la SELECT.
4. Se puede definir una "vartable" con atributo RIGHT.
5. Posibilidad de utilizar la instrucción PROMPT FOR con una etiqueta variable. Por ejemplo:
prompt for a using "Literal1 ",variable," Literal 2"
o
prompt for a using b
6. Posibilidad de utilizar programas tform que contengan más de 15 LOOKUP con otras tablas.
7. La instrucción DISPLAY SELECT permite seleccionar, mediante la cláusula SET, cuando en dicha instrucción intervienen condiciones con variables host que sean columnas de la tabla que se está manteniendo.
8. Tanto en Tform como en T4gl se ha implementado la cláusula NOWAIT en la definición de cursores para controlar los bloqueos en aquellos definidos con la cláusula FOR UPDATE. La forma de definir un cursor con esta cláusula es la siguiente:
declare cursor nombre for select
campo1,campo2
into $a,$b from tabla
for update campo1 nowait
Con esta definición, en el momento que dos usuarios o más coincidan en la misma fila para actualizar, el segundo que intente hacerlo pasará a la siguiente fila sin que se quede bloqueado, esperando al desbloqueo. Por defecto, si se define un cursor sin la cláusula NOWAIT, implicará que en el momento en que una instrucción FETCH o FOREACH lea una fila, ésta quedará bloqueada automáticamente.
9. En estos momentos no existe límite de definición de variables en ninguno de los lenguajes.
10. La exponenciación funciona con exponentes decimales en cualquier lenguaje.
1. Los parámetros de la sección OUTPUT pueden tomar valores variables. Por ejemplo:
output
top margin var1
bottom margin var2
left margin var3
right margin var4
page length var5
end
2. La función LETTER se puede alterar mediante la modificación del fichero fuente "C" que se encuentra en el directorio "msg" del "trans". El nombre de este programa fuente de "C" es "$TRANSDIR/MSG/NBRTOSTR.C". Esta rutina se encuentra en las versiones de español e inglés.
3. La longitud total de una instrucción RUN se ha ampliado de 160 a 1.024 bytes.
1. Posibilidad de lanzar programas T4gl en background, vía "&" o con los comandos "cron" y "at", mediante la utilización de la opción -b del T4gl.
run t4gl "programa" "&"
Dentro del "cron" deberíamos especificar el siguiente comando:
t4gl -b programa &
2. En esta versión ya se puede ejecutar un programa TMENU con un "run" desde el T4GL. Anteriormente, en el momento que se ejecutaba un programa de tipo tform en el menú, la pantalla se desconfiguraba.
3. La instrucción DISPLAY SELECT con condiciones se comporta de forma correcta en su ejecución.
4. Posibilidad de utilizar la instrucción PROMPT FOR con el atributo "reverse".
5. Para que la instrucción CLEAR FRAME actúe debe ser seguida por la instrucción VIEW o por cualquiera que provoque el "refresco" de pantalla.
6. Posibilidad de utilizar la instrucción EXIT INPUT dentro de los INPUT FRAME.
7. Permite crear una tabla temporal mediante la cláusula INTO TEMP de la instrucción SELECT y poder utilizarla posteriormente en el mismo programa.
8. En esta versión podemos definir un "frame nombre like tabla.*". A la hora de hacer INPUT o DISPLAY tomará los atributos especificados en el diccionario al definir dicha tabla.
database base_datos
define
frame nombre like tabla.*
end
end
main begin
...
...
9. Las funciones "keylabel" y "keyfunction" devuelven nulos en caso de que la tecla indicada no tenga ninguna función asignada.
10. La instrucción CONTINUE tiene un comportamiento correcto. En esta versión vuelve al principio del bucle que se está ejecutando y no al principio del programa, como ocurría en versiones anteriores.
Las modificaciones llevadas a cabo en la versión 3.0.08 respecto a las anteriores son las siguientes:
1. Se ha incorporado la directiva de compilación INCLUDE sobre todos los lenguajes (Tform, Treport, T4gl y Tmenu). Esta directiva permite que el compilador utilice como parte del programa fuente el fichero indicado. Su sintaxis es la siguiente:
$INCLUDE "fichero"
El nombre del fichero puede especificarse con su path completo. En caso de no especificarlo, o de especificar un path relativo, se utilizará la variable de entorno DBINCLUDE para localizarlo. El valor por defecto de esta variable es el directorio en curso. En un programa se puede especificar más de una directiva INCLUDE, consiguiendo de esta forma dividir un programa fuente. Por ejemplo:
database almacen
screen
{
etiqueta [a ] etiqueta 1 [b ]
}
end screen
tables
...
end tables
$include "f_menu"
control
...
...
end control
end form
Fichero "f_menu"
menu "Principal"
option "Añadir"
add
option "Modificar"
modify
option "Borrar"
remove
option "Consultar"
query
end menu
Este fichero podrá ser llamado desde cualquier programa con la directiva INCLUDE, sin necesidad de definirlo en todos ellos.
2. Por otra parte, se incorpora también la variable de entorno SYSPATH. Esta variable, en el caso de especificarse, indica el "path" donde se encuentran todas las tablas del catálogo del SQL (no del trans) de una base de datos: systables, syscolumns, sysindexes, systabauth y syscolauth. Los requisitos imprescindibles para su funcionamiento son:
—Las tablas "sys*" deben encontrarse debajo de un directorio "base_datos.dbs". Ejemplo:
SYSPATH=/usr/dir_base_datos_con_sys
export SYSPATH
Las tablas "sys*" estarán en:
/usr/dir_base_datos_con_sys/bdatos.dbs
—Las restantes tablas de la base de datos, junto con la SYSTABLES.*, pueden encontrarse en otro directorio, también debajo de un directorio "base_datos.dbs". Este path se especifica en la variable de entorno DBPATH o se asume el directorio en curso.
—No es necesario cambiar los "dirpath" de las tablas dentro del systables.
3. Se ha ampliado la variable DBPROC a 256 caracteres en el Treport. Los path individuales no deben superar los 80 caracteres. Por ejemplo:
DBPROC=/usr/direc1:/usr/direc2
export DBPROC
4. El error descrito en las notas técnicas de la versión 3.0.07 sobre la llamada desde un t4gl al tmenu ya ha sido corregido en la versión 3.0.08.
Imprimir